likely bug in FPC v3.2.2 handling of booleans

[Martin_fr]

Ha, ok, it is (maybe) why it exists type boolean32. 
But how would you do to create a "checksum" (very nice idea to check if the value has all the right).

"chekcsum" does not need to be computed. It could be a specific pattern. Bitrot would be unlikely to translate it into exactly one of the 2 valid patterns.

And no, its not the reason for boolean32 => Most likely that is
- easy of implementation
- optimization

Both of which, I guess, would be "not a reason" for 440bx. But they may have been for the decision makers. If so, the rest of us has to accept it.

We already clarified that the before mention boolean in maths has no say on the storage form => therefore it also does not dictate a minimum storage or single bit.

Hence we can store it in a multi byte storage, and we can demand that all bits are set according to the encoding, and that values not matching the encoding are undefined. (We know it can be done. It has already be done)

[Fred vS]

Thanks Martin for the always clear answer.

To stupid me:

With this example:

Code: Pascal  [Select][+][-]

1. var
2. abol : boolean32;
3. ...
4. begin
5. abol := boolean32(123456789);  // the integer <> 0 that will set abol as "true"
6. writeln(word(abol));

the result is 52501, so what is the relation with 123456789?

It is because you used word that is 16 bit size and boolean32, 32, coño. 
(longint is ok.)

[Martin_fr]

Code: Pascal  [Select][+][-]

1. var
2. abol : boolean32;
3. ...
4. begin
5. abol := boolean32(123456789);  // the integer > 0 that will set abol as "true"
6.  

I didn't pay much attention to the example, sorry...

But, it is wrong. The comment is wrong. It would be true for a LongBool.

But a boolean32 is only true if set to the ordinal value 1. Any value other than 0 or 1 will set it to undefined.

[Fred vS]

Code: Pascal  [Select][+][-]

1. var
2. abol : boolean32;
3. ...
4. begin
5. abol := boolean32(123456789);  // the integer > 0 that will set abol as "true"
6.  

I didn't pay much attention to the example, sorry...

But, it is wrong. The comment is wrong. It would be true for a LongBool.

But a boolean32 is only true if set to the ordinal value 1. Any value other than 0 or 1 will set it to undefined.

Ha, I miss something then.

This:

Code: Pascal  [Select][+][-]

1. var
2. abol : boolean32;
3. ...
4. begin
5.   abol := boolean32(-123456789); // <> 0 = true
6.  writeln(longint(abol));
7.  if abol then writeln('it is true');
8. ...

gives that as result:

Code: Pascal  [Select][+][-]

1. -123456789
2. it is true

[Martin_fr]

Yes undefined behaviour can print true.

But see the code here https://forum.lazarus.freepascal.org/index.php/topic,70004.msg545161.html#msg545161

[Fred vS]

Yes undefined behaviour can print true.

But see the code here https://forum.lazarus.freepascal.org/index.php/topic,70004.msg545161.html#msg545161

OK, thanks (and I have to confess that I have problem with the concept of boolean (0 or 1, true or false, plus or minus, black or white).
Binary in fact does not exist in reality, see math, electric, ..., it is -, 0, + (ternary not binary).
But this is a other story.

[440bx]

But a boolean32 is only true if set to the ordinal value 1. Any value other than 0 or 1 will set it to undefined.

That really begs the question: why does the compiler allow it to be set to an "undefined" value when it has all the necessary information to prevent it ?

The compiler doesn't even emit a hint or a warning to draw the programmer's attention to the incorrect/invalid/"undefined territory" (choose whichever adjective is more palatable) situation.  Emitting a hint or warning should be acceptable... no ? (or do we want to hide the fact that booleans can be set to values other than 0 and 1 under the binary rug ?)

Basically, if the programmer creates a statement the compiler should reject, it's not a flaw that the compiler didn't reject the incorrect statement, the real problem is: the programmer should not have found that flaw.. much less use it in spite of the fact that the compiler pretends it is perfectly acceptable.

Anyway, what's really sad is that because Delphi has the same "deficiency", FPC will use that as the reason to keep it that way.

However, on a related note, shouldn't the documentation be updated to inform the programmer of the fact that booleans may be set to values other than TRUE and FALSE but those are the only values that will produce correct results.  That's the reality, the documentation should "probably" reflect that.

[dsiders]

However, on a related note, shouldn't the documentation be updated to inform the programmer of the fact that booleans may be set to values other than TRUE and FALSE but those are the only values that will produce correct results.  That's the reality, the documentation should "probably" reflect that.

Did you submit a patch?

[440bx]

Did you submit a patch?

No, because I do not believe that anything is going to change. 

I believe that both, the compiler and the documentation will remain _exactly_ the way they are with, in the best case, _one_ possible exception which is: the compiler might be enhanced to emit a hint or warning if an invalid cast to boolean is made.  Honestly, I would be surprised if that happened (pleasantly though.)