Boolean Data Type in freebasic

[St_W]

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]

@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]

@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]

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]

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]

'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]

'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]

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]

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]

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]

See at changelog - FreeBasic Compiler MinGW.htm
Tested this morning with fbc_win32_mingw_0367_2015-09-11.zip

[MrSwiss]

@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]

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

See at http://www.freebasic.net/forum/viewtopi ... 28#p210128.
With Firefox, I must often also refresh the page to see the last upload.

[fxm]

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]

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.

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).