Boolean type

[440bx]

You keep doing a mix of ignoring and misrepresenting it. Your choice. Valid choice as well, but not a choice on which I will waste my time.

I don't think I"m ignoring or misrepresenting anything. 

By definition Boolean is 2 states.  If we accept the traditional convention of 0 and 1 to denote those 2 states and 0 to represent FALSE and 1 to represent TRUE then FPC does NOT implement booleans.  What it implements is C's bastardized BOOL type but, it definitely does NOT implement boolean and that is readily seen in the code it generates.  No boolean implementation can use test al, al or test ax, ax to determine if the value is 1 since those tests determine 0 and non-zero.  They do not test for the value 1 which is what boolean requires and also what the documentation specifies.

It would be kind of nice if the compiler behaved as the documentation states it does (which it simply does not in the case of boolean.)

There is no way around it.  FPC does NOT behave as documented and does NOT treat the boolean type as documented.  If it did, the code it would generate for them would be quite different from the code it's generating today.

[Martin_fr]

You keep doing a mix of ignoring and misrepresenting it. Your choice. Valid choice as well, but not a choice on which I will waste my time.

I don't think I"m ignoring or misrepresenting anything. 

By definition Boolean is 2 states. 

Even when G.Boole did it (presumingly on paper, but it does not matter what media), there was a chance of unclear representation. And if he (or any human) encountered such a case they needed to deal with it (and if they did not recognise it, then the result was unpredictable).

More so, someone could have written a 2 in an bool equation on paper. That would have invalidated the expression of course (just as it does now, when you do Boolean(2)). So we follow the exact same rules. Once invalidated the result is undefined. (because undefined was chosen over an exception).

I do understand that you believe that now we have the chance to chose a representation (single bit) that can not be mis-read. But that choice has not been made. And G.Boole himself used representations that did not enforce others to stick to those 2 tokens. In all of time, others were able to write tokens (on paper) that were invalid.

So, all it is, is that the possibility to break the rule (of only using the 2 valid tokens) is still available to the user.

By definition Boolean is 2 states. 

And so does it have in FPC.

All else is user error.

The only thing that I can see as a point (in all of your statements) is that user error is not prevented. Though if that is what you try to say, then you do that in a really obscured and definitely misleading way.

[Thaddy]

1. Boolean implementations as opposed to definitions are not two states but infinity - 1 since optimizations lead to loss ofthe two state accuracy.
Optimizers seem to accept the only solid value of the two theoretical states is false. But that implies that true is infinity, since infinity - 1 is also infinite.
2. Compilers should not play such dangerous games with optimizers.
I repeat my proof from two years ago:

Code: C  [Select][+][-]

1. #include <stdio.h>
2. #include <stdbool.h> /* optional in GNU 12 and higher */
3. void mycfunc(_Bool arg){
4.         printf("number: %d\n",arg?1:2);
5. }

Compile with and without optimization and shiver....
Same goes if you build it with clang.
Both compilers only adhere to the two state 0 and 1 without optimizations.
Both compilers document Bool is 0 and 1...
Go figure....

[440bx]

And so does it have in FPC.

NO, that's the fallacy.  The fact that FPC uses instructions such as test al, al and test ax, ax to determine the truth value _proves_ that what FPC is implementing is NOT a true, 2 state only, 0 and 1, boolean type.  It is implementing C's BOOL thing which is 0 = FALSE any other value = TRUE (that's 255 additional states) which is in direct contradiction to the documentation.

FPC does not implement a true boolean type.  It implements C BOOL type which is similar but also very different.  Since there are times it is forced to treat boolean as a real boolean, e.g, when bitpacking, then it falls over itself as was shown in the tread I previously linked to.

There is no undefined behavior, what there is, is well defined, completely incorrect implementation.   

It's not hard to implement the real boolean type, a simple "and reg, 1" does it.

[Thaddy]

@440bx
You are right but it depends on optimization and you are focussing on just one cpu family.
My above test library is a better way to prove your point for external libs.
I believe that trunk does not optimize true/false anymore for Boolean,but it does for BOOL, same as C _Bool.

[Martin_fr]

And so does it have in FPC.

NO, that's the fallacy. 

Yes, it does
And I explained how/why.

[440bx]

Yes, it does
And I explained how/why.

Martin, you cannot argue this. 

The compiler generates code that tests entire bytes/words/dwords/etc depending on the size of the boolean.  THAT proves beyond any possible argument that FPC is NOT treating a boolean as a two state entity.  The treatment it gets is: 0 = FALSE and 1 through 255 (or high(type)) = TRUE.  That doesn't remotely resemble two unique ways of representing TRUE and FALSE.

FPC has 1 state for FALSE and umpteen states for TRUE and the way it treats them is erratic which is why the whole thing falls apart when mixing them with bitpacked booleans and also why there are cases in FPC where TRUE <> TRUE (refer back to the example I gave based on your code.)  If FPC implemented the boolean type correctly TRUE would always equal TRUE.

result: there are no true booleans in FPC.  Only C's BOOL.

The FPC documentation states how a boolean _should_ be, definitely not the way it is in FPC.

[Martin_fr]

Yes, it does
And I explained how/why.

Martin, you cannot argue this. 

Agreed. I can only state the facts. I did.

You misrepresent them. (You represent various facts, but mix/cross different contexts leading to an incorrect result)

[Khrys]

Explicit casts from integer to boolean like  Boolean(2)  should at the very least generate a warning, or better yet actually enforce FPC's purported principle that  Integer(True) = 1  by inserting extra code for such casts.

In my opinion, the mere presence of undefined behavior isn't the problem here, but the fact that it can be triggered so easily without warning - it's a footgun with a silencer attached.

[LemonParty]

Thank you for answers.
My desire was to determine if I can write code like this:

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

1. function Pick(B: Boolean): Integer;
2. const
3.   Resp: array[Boolean]of Integer = ($13, $42);
4. begin
5.   Result:= Resp[B];
6. end;
7.  

[cdbc]

Hi
You can!
Regards Benny

[Martin_fr]

Thank you for answers.
My desire was to determine if I can write code like this:

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

1. function Pick(B: Boolean): Integer;
2. const
3.   Resp: array[Boolean]of Integer = ($13, $42);
4. begin
5.   Result:= Resp[B];
6. end;
7.  

Ok, so the answers where completely off....


You could try an operator overload. Something like

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

1. Operator := (val: integer): Boolean;

You need to check the exact details (and if FPC will accept it at all)

[440bx]

Agreed. I can only state the facts. I did.

Here is a FACT: in FPC two expressions that are TRUE are considered to be unequal, IOW, TRUE <> TRUE.  THAT is a FACT in FPC.  There is NO undefined territory in the whole universe that can justify that.

I didn't misrepresent anything.  I stated the facts and if you need to see them again, look at the two lines I added to your code.  That proves what I've stated.  Also, the FACT that FPC uses test al, al and test AX, AX proves it is considering any non zero value as TRUE.  Those are FACTS and I do not understand how you can possibly attempt to argue them. 

Look at the assembly code.  It's right there.

[440bx]

Thank you for answers.
My desire was to determine if I can write code like this:

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

1. function Pick(B: Boolean): Integer;
2. const
3.   Resp: array[Boolean]of Integer = ($13, $42);
4. begin
5.   Result:= Resp[B];
6. end;
7.  

It should work but, I still would be careful with writing something like that because the value of B is NOT guaranteed to be in the set [0, 1].  It can be any value ranging from zero to 255.  That said, if your code can guarantee that the value of B will be 0 or 1 then there is no problem, just don't expect the compiler to guarantee B to be zero or 1, it does not.

[Martin_fr]

Agreed. I can only state the facts. I did.

Here is a FACT: in FPC two expressions that are TRUE are considered to be unequal,

There aren't true (as far as any example that I have been shown). They are undefined. As soon as you use typecast (except for the ordinal 0 ad 1), you no longer have "boolean".