probabily oldest freebasic bug :P

General FreeBASIC programming questions.
Mysoft
Posts: 836
Joined: Jul 28, 2005 13:56
Location: Brazil, Santa Catarina, Indaial (ouch!)
Contact:

probabily oldest freebasic bug :P

Post by Mysoft »

Code: Select all

function ShowNum( iNum as long ) as long
  print iNum
  return 50
end function

ShowNum(5)+ShowNum(10)
sleep
so on windows tried with versions from 0.15 to 1.09... (32bit) with/without -gen gcc all same results
it prints 10 and 55 ...

if storing the result instead of discarding then it shows the right ones... 5 and 10.
TeeEmCee
Posts: 375
Joined: Jul 22, 2006 0:54
Location: Auckland

Re: probabily oldest freebasic bug :P

Post by TeeEmCee »

That's because it's parsed as

Code: Select all

ShowNum((5)+ShowNum(10))
I believe this is actually intentional behaviour, though I'm not so happy with it. It causes other problems too (and is a backcompat break to change). In nearly any other programming language, the function call operator () always has higher precedence than math operators such as +, but statements as opposed to expressions parse differently in FB.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: probabily oldest freebasic bug :P

Post by fxm »

I expected 'ShowNum(5)+ShowNum(10)' line to induce compiler error message.
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: probabily oldest freebasic bug :P

Post by angros47 »

The behavior is indeed correct: to achieve the result 5 and 10 you should use:

Code: Select all

dim i as integer
i=ShowNum(5)+ShowNum(10)
in fact, in FreeBasic a FUNCTION can also be invoked as if it were a SUB (that is not possible in QBASIC, but is possible in C): also, while in C a command must have its parameters between parenthesis, in FreeBasic that is not needed.

So, the parser encounters ShowNum, and assumes that the rest of the line ((5)+ShowNum(10)) is its parameters. In the syntax I just showed you, instead, parameters must be between parenthesis, so there is no doubt that only the "5" is a parameter for the first ShowNum
Kuan Hsu
Posts: 586
Joined: Sep 16, 2007 15:12
Location: Taiwan

Re: probabily oldest freebasic bug :P

Post by Kuan Hsu »

fxm wrote: Jun 15, 2022 5:00 I expected 'ShowNum(5)+ShowNum(10)' line to induce compiler error message.
GO language: ShowNum(5) + ShowNum(10) evaluated but not used
D language: Error: `ShowNum(5) + ShowNum(10)` has no effect
gcc 8.1: pass, output is 5 and 10
tcc 0.9.24: pass, output is 5 and 10
TeeEmCee wrote: Jun 15, 2022 2:52 That's because it's parsed as

Code: Select all

ShowNum((5)+ShowNum(10))
I believe this is actually intentional behaviour, though I'm not so happy with it. It causes other problems too (and is a backcompat break to change). In nearly any other programming language, the function call operator () always has higher precedence than math operators such as +, but statements as opposed to expressions parse differently in FB.
The next token of first ShowNum should be open paren, Why the parser need add another ()?
TeeEmCee
Posts: 375
Joined: Jul 22, 2006 0:54
Location: Auckland

Re: probabily oldest freebasic bug :P

Post by TeeEmCee »

Kuan Hsu wrote: Jun 15, 2022 13:21 The next token of first ShowNum should be open paren, Why the parser need add another ()?
I think you misunderstood me. And I don't understand you. I do not wish that it has to be written like "ShowNum((5)+ShowNum(10))".
dodicat
Posts: 7976
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: probabily oldest freebasic bug :P

Post by dodicat »

Freepascal
shownumber(5)+shownumber(10);
Error: Illegal expression

C and C++
shownumbers(5)+shownumbers(10);

5
10

Comment:
I would expect this of pascal, it is extremely fussy.

C and C++
Seems more logical.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: probabily oldest freebasic bug :P

Post by caseih »

I guess it never occurred to me to call two subroutines by trying to add them together! I assume that this bug is not present if you are constructing an expression, such as assignment or passing the result to another function, correct?
hhr
Posts: 205
Joined: Nov 29, 2019 10:41

Re: probabily oldest freebasic bug :P

Post by hhr »

Yes, the program is a perversion.
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: probabily oldest freebasic bug :P

Post by angros47 »

Again, it is not a bug. It is how FreeBasic is supposed to act

in the old QBASIC functions could be invoked only inside expression, so an attempt to write "ShowNum(5)" would have caused an error, it should have been a sub to work

In C, on the other hand, it's possible to use a function as if they were subroutines (the equivalent of a FreeBasic SUB in C is a void function). FreeBasic works like C, in that, accepting commands like "ShowNum(5)" as well

Still, the syntax "shownumber(5)+shownumber(10)" is not valid, because it performs a sum and does not put the result anyware. To see what is wrong with that, try this:

Code: Select all

dim p as long
p+p
Compiler will return "error 10: Expected '=', found 'p' in 'p+p'"

If we try to do the same with functions, like:

Code: Select all

function foo as long
return 1
end function

foo+foo
the error would be "error 3: Expected End-of-Line, found '+' in 'foo+foo'"

In the old QBASIC, there was another difference between SUBs and FUNCTIONs: a function required parameters to be between parenthesis, a sub required no parenthesis to be used. So, if ShowNum were a SUB, it should have been used as "ShowNum 5", not as "ShowNum(5)".
FreeBasic accepts both syntax, so using "ShowNum 5" is allowed

So, what happens with the line "ShowNum(5)+ShowNum(10)"? If FreeBasic tries to evaluate ShowNum(5), then ShowNum(10), and then to sum them together, it would end in a situation similar to the example "foo+foo", and it should return an error. But if FreeBasic evaluates that line as "ShowNum" with "5+Shownum(10)" as argument, the syntax is correct: first of all, it should solve the expression "(5)+ShowNum(10)", so it calls the function "ShowNum(10)" that prints on the screen the number 10, and returns the number 50, then it adds 5 to 50. Then, it invokes ShowNum on the result (that is 5+50, so 55), and prints that number.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: probabily oldest freebasic bug :P

Post by fxm »

I understand what you mean.

When FreeBASIC calls a function without using its return value, syntax without parentheses surrounding the parameter(s) is allowed.
In this specific case, the parameter would be '(5)+ShowNum(10)'.
But the only thing that bothers me in this hypothesis is that there is no space between the function name and the supposed passed parameter.
speedfixer
Posts: 606
Joined: Nov 28, 2012 1:27
Location: CA, USA moving to WA, USA
Contact:

Re: probabily oldest freebasic bug :P

Post by speedfixer »

Either way, I think there should be some unambiguous documentation that could be used to accept one resolution or another.

Does that exist?

While not simply BASIC, FreeBASIC is still *some* flavor of BASIC:
there should be no surprises for a beginner.

david
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: probabily oldest freebasic bug :P

Post by caseih »

angros47 wrote: Jun 15, 2022 21:40Again, it is not a bug. It is how FreeBasic is supposed to act
Yes I understand that. Sorry to call it a bug. Quirk is more appropriate! I definitely maintain that calling two subs and adding them together is probably not a good practice anyway, even in languages that don't exhibit this quirk, like C.

Speaking of quirks and syntax, just saw an EEVBlog video on the problem with the expression "6/2(2+1)" and how the answer is either 9 or 1 depending on whether the calculator treats implicit multiplication with a higher precedence than ordinary multiplication and division. Even today calculators often disagree on this depending on where the calculator was made.
Mysoft
Posts: 836
Joined: Jul 28, 2005 13:56
Location: Brazil, Santa Catarina, Indaial (ouch!)
Contact:

Re: probabily oldest freebasic bug :P

Post by Mysoft »

heh indeed but i say it would require a space for it to be taken as a function without parenthesis... but oh well, i missed that possibility because of the immediate parenthesis, but indeed...

and as i said it only happen when the value is not being set yes :)

and yeah despite the code being "unusual"... it reached that point naturally since i was testing some precedence ordering :)
Last edited by Mysoft on Jun 16, 2022 1:54, edited 1 time in total.
Mysoft
Posts: 836
Joined: Jul 28, 2005 13:56
Location: Brazil, Santa Catarina, Indaial (ouch!)
Contact:

Re: probabily oldest freebasic bug :P

Post by Mysoft »

Kuan Hsu wrote: Jun 15, 2022 13:21
fxm wrote: Jun 15, 2022 5:00 I expected 'ShowNum(5)+ShowNum(10)' line to induce compiler error message.
GO language: ShowNum(5) + ShowNum(10) evaluated but not used
D language: Error: `ShowNum(5) + ShowNum(10)` has no effect
gcc 8.1: pass, output is 5 and 10
tcc 0.9.24: pass, output is 5 and 10
TeeEmCee wrote: Jun 15, 2022 2:52 That's because it's parsed as

Code: Select all

ShowNum((5)+ShowNum(10))
I believe this is actually intentional behaviour, though I'm not so happy with it. It causes other problems too (and is a backcompat break to change). In nearly any other programming language, the function call operator () always has higher precedence than math operators such as +, but statements as opposed to expressions parse differently in FB.
The next token of first ShowNum should be open paren, Why the parser need add another ()?
gcc/tcc also have the warning but its disabled by default... "has no effect" from D sounds weird as there is an effect by the call to the function but yes... guess on D it being an error is... meh
Post Reply