Boolean Data Type in freebasic

For other topics related to the FreeBASIC project or its community.
St_W
Posts: 1467
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: Boolean Data Type in freebasic

Postby St_W » Sep 10, 2015 15:02

Code: Select all

Function getB() As Boolean
   Return FALSE
End Function

Dim result As boolean
Dim A As boolean = TRUE

result = A AndAlso getB()


results in the following compiler warning (current git build of fbc 1.04):
test2.bas(8) warning 38(0): Mixing operand data types may have undefined results

Why?

A is bool, function result of getB is bool, (A andalso B) should be bool, result is bool.
MrSwiss
Posts: 3128
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Boolean Data Type in freebasic

Postby MrSwiss » Sep 10, 2015 15:18

@St_W,

try lowercase on true/false. This is AFAIK the way it's defined in FB 1.04.0. It is not that alone, mainly:
it is the AndAlso (which returns something else than Boolean), it works with a simple And without Warnings by compiler ...

Code: Select all

Function getB() As Boolean
   Function = false
End Function

Dim As Boolean   result, A = true

result = A And getB()

Locate 2, 2 : Print "Result: " & result
Sleep
St_W
Posts: 1467
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: Boolean Data Type in freebasic

Postby St_W » Sep 10, 2015 16:36

MrSwiss wrote:@St_W,
try lowercase on true/false. This is AFAIK the way it's defined in FB 1.04.0. It is not that alone, mainly:
it is the AndAlso (which returns something else than Boolean), it works with a simple And without Warnings by compiler ...


FreeBasic is case insensitive. Whether one uses UPPER/lower/mIXeD case in the code is (or at least should be) completely irrelevant.

"AndAlso" seems to cause of the problem and I would consider this as a bug in fbc. "And" doesn't trigger this compiler warning (but of course does call getB even if A = false; that's what "AndAlso" is for).
fxm
Posts: 9021
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Boolean Data Type in freebasic

Postby fxm » Sep 10, 2015 16:49

Same behavior for OrElse.
I think that simply AndAlso and OrElse are not still allowed to be used as Boolean operators in the current FreeBASIC.
MrSwiss
Posts: 3128
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Boolean Data Type in freebasic

Postby MrSwiss » Sep 11, 2015 8:08

There is at least one more issue: CBool()
"convert to boolean" is also not working as expected:

Code: Select all

Function getB() As Boolean
   Function = false
End Function

Dim As Boolean   result, A = true

Locate 1, 2 : Print "CBool() test - FBC 1.04.0"

result = CBool( A AndAlso getB() )      ' <-- doesn't work as advertized
Locate 4, 2 : Print "Result: " & result, "CBool( A AndAlso getB() )"

Locate 9, 2 : Print "Any key exits ... ";

Sleep

Are there plans to fix above issues in 1.04.0 soon?

I've tried to find a solution for the AndAlso/OrElse case, but the result is:
... warning 38(0): Mixing operand data types may have undefined results
fxm
Posts: 9021
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Boolean Data Type in freebasic

Postby fxm » Sep 11, 2015 9:04

'Cbool()' works.
It's always 'AndAlso' (and 'OrElse') which is not fully compatible with booleans.

A workaround with 'AndAlso' to suppress the warning and return a boolean:

Code: Select all

Function getB() As Boolean
    Function = false
End Function

Dim As Boolean A = true

Print Cbool( Cast(Byte, A) AndAlso Cast(Byte, getB()) )

Sleep
MrSwiss
Posts: 3128
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Boolean Data Type in freebasic

Postby MrSwiss » Sep 11, 2015 11:25

fxm wrote:'Cbool()' works. <-- wrong on expression (decimal)

Manual states ...

Code: Select all

Dim As Boolean   boolr1, boolr2, boolr3, boolr4

Print

boolr1   = CBool(127)            ' should give "true"   <-- "warning 25(0): Overflow in constant conversion"
boolr2   = CBool(-1)               ' should give "true"   OK
boolr3   = CBool(&h01FF)            ' should give "true"   <-- "warning 25(0): Overflow in constant conversion"
boolr4   = CBool("0")            ' should give "false"   OK

Print "boolr1: " & boolr1, "boolr2: " & boolr2, "boolr3: " & boolr3, "boolr4: " & boolr4
Print
boolr1   = CBool(1270000)         ' should give "true"   <-- "warning 25(0): Overflow in constant conversion"
boolr2   = CBool(&hFFFFFFFFFFFFFFFF)   ' should give "true"   OK
boolr3   = CBool(&h0000000000000000)   ' should give "false"   OK
boolr4   = CBool("23")            ' should give "true"   OK
Print "boolr1: " & boolr1, "boolr2: " & boolr2, "boolr3: " & boolr3, "boolr4: " & boolr4
Print

Sleep

First test: BUILD 0340 ...
Just to make certain: tested with the latest BUILD 0365 DATE 2015-09-10, exactly the same behaviour.
dkl
Site Admin
Posts: 3207
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Boolean Data Type in freebasic

Postby dkl » Sep 11, 2015 16:14

Hi,

The issue with AndAlso/OrElse causing a warning if both operands are booleans is fixed in Git now. It should of course only warn if operands really are mixed.

Also, the warnings shouldn't appear anymore now if mixing booleans with 0/-1 (e.g. true and (-1)), or integers with true/false (e.g. 123 and true). If I remember correctly, that's how it was intended, it was just not working. This gives better backwards compatibility with code which used the old-school integer TRUE/FALSE definitions.

cbool() on the other hand is working fine I think - it will trigger a "constant conversion overflow" warning for any values besides 0, -1, 1. That's not too bad, we have similar behavior for other types, e.g. cbyte(&hFFFF) gives this warning too.
fxm
Posts: 9021
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Boolean Data Type in freebasic

Postby fxm » Sep 12, 2015 5:14

dkl wrote:The issue with AndAlso/OrElse causing a warning if both operands are booleans is fixed in Git now.

Yes but when the two operands are boolean, the AndAlso & OrElse operators return an integer instead of a boolean:

Code: Select all

Print true And true
Print false And true
Print false Or true
Print true Or false
Print
Print true Andalso true
Print false Andalso true
Print false Orelse true
Print true Orelse false

Sleep

Code: Select all

true
false
true
true

-1
 0
-1
-1

Code: Select all

Print -1 And -1
Print 0 And true
Print false Or -1
Print true Or false
Print
Print -1 Andalso -1
Print 0 Andalso true
Print false Orelse -1
Print true Orelse false

Sleep

Code: Select all

-1
 0
-1
true

-1
 0
-1
-1
MrSwiss
Posts: 3128
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Boolean Data Type in freebasic

Postby MrSwiss » Sep 12, 2015 9:57

fxm wrote:Yes but when the two operands are boolean, the AndAlso & OrElse operators return an integer instead of a boolean

fxm is right, below an excerpt from ast_node_bop.bas on GitHub (2015-09-12):

Code: Select all

... Starting at Line 978:
   '' Any boolean operand(s)?
   if( (typeGetDtAndPtrOnly( ldtype ) = FB_DATATYPE_BOOLEAN) or _
       (typeGetDtAndPtrOnly( rdtype ) = FB_DATATYPE_BOOLEAN) ) then
      select case as const op
      case AST_OP_AND, AST_OP_OR, AST_OP_XOR, AST_OP_EQV, AST_OP_IMP, _
          AST_OP_EQ, AST_OP_NE
         '' Don't promote booleans to integers, so we can have
         '' "pure-boolean" BOPs (that also return booleans).
         is_boolean = TRUE

      case AST_OP_ANDALSO, AST_OP_ORELSE
         '' TODO: should do that for AndAlso/OrElse too,
         '' but it caused backwards-compatibility problems with
         '' fbc sources...

      case else
         '' No other BOP's allowed with booleans
         exit function
      end select
...

Maybe you (dkl) didn't commit/merge the changes you've made ...
Also, there wasn't a new FBC build triggered last night (indicating: no change in source)?
fxm
Posts: 9021
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Boolean Data Type in freebasic

Postby fxm » Sep 12, 2015 10:04

MrSwiss
Posts: 3128
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Boolean Data Type in freebasic

Postby MrSwiss » Sep 12, 2015 10:08

@fxm,
I'm talking about the x64 ver. WIN ...

sorry, must have had a cache issue with the browser, everything OK.

ATTENTION:
I've just noted that the build numbers on 32/64 Windows are NOT the same (at the same Date).
32bit == 0367 == today (last night)
64bit == 0368 == today (last night)
so one should NOT rely to much on the build # alone!
fxm
Posts: 9021
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Boolean Data Type in freebasic

Postby fxm » Sep 12, 2015 14:07

MrSwiss wrote:sorry, must have had a cache issue with the browser, everything OK.

See at viewtopic.php?p=210128#p210128.
With Firefox, I must often also refresh the page to see the last upload.
fxm
Posts: 9021
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Boolean Data Type in freebasic

Postby fxm » Sep 13, 2015 5:32

fxm wrote:
dkl wrote:The issue with AndAlso/OrElse causing a warning if both operands are booleans is fixed in Git now.

Yes but when the two operands are boolean, the AndAlso & OrElse operators return an integer instead of a boolean

dkl, thanks for the fix:
boolean: Allow AndAlso/OrElse to return boolean
St_W
Posts: 1467
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: Boolean Data Type in freebasic

Postby St_W » Sep 14, 2015 10:37

The compiler warning disappeared with the latest build (#371 win32) - thank you, dkl - , but the problem mentioned by fxm seems to be not fixed yet:

Code: Select all

    Function getB() As Boolean
        Return FALSE
    End Function

    Dim result As boolean
    Dim A As boolean = TRUE

    result = A AndAlso getB()
    Print A AndAlso getB()      'output: 0
    Print result                        'output: false

The first print results in a "0" output instead of "false". Removing/adding outer parantheses does not change anything.

I'm also totally aware that I'm using a build of work-in-progress code, not a final release build. I just want to report/(document) suspective behaviour I've encountered. Maybe there are some issues that are already known, but I've simply not heard about them yet.

MrSwiss wrote:ATTENTION:
I've just noted that the build numbers on 32/64 Windows are NOT the same (at the same Date).
32bit == 0367 == today (last night)
64bit == 0368 == today (last night)
so one should NOT rely to much on the build # alone!

Yes that's right. It was only a nice coincidence that the win32/win64 build numbers were aligned for a longer period of time. In fact each platform build is independant from the others, therefore a changelog exists for each platform. Maybe I can modify the process to synchronize the build numbers, but Jenkins (the CI server I am using for the builds) is not designed to have multiple builds accessing the same checkout, but rather each build using its own checkout (yet, there do exists plugins/process patterns to model that behaviour too).

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 3 guests