Strange behaviour of BOOLEAN type

[Martin_fr]

Off topic to the original thread....

Afaik there are API calls (kernel, etc) that may return "boolean", but with -1 or even just non-zero for true.
But maybe there are other reasons....


Anyway, "boolean" in Pascal has exactly 2 values: true and false. And it only deals with those 2 (and there exact ordinal values 0 and 1).

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

1. var b: boolean;

Forcing any ordinal that is not the ordinal of true or false into "b" is invalide code, and will not work. And is not expected to work.

So as far as I can see, this is exactly what it should be.

In order to deal with API calls as those mentioned, there are additional types in Pascal. E.g. "ByteBool".
- ByteBool is not (type) boolean.
- ByteBool behaves like boolean.
- ByteBool can be assigned to boolean.
- ByteBool is a type of its own (just like byte or word are types of their own)

ByteBool treats non-zero as true.

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

1. MyBoolean := MyByteBool;

is internally translated into

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

1. MyBoolean := Byte(MyByteBool) <> 0;

And therefore the boolean will store the value "true" with an ordinal value of 1.

And that has been existed for a long time (maybe not in Turbopascal, I have not checked). However it does not break "boolean", it just adds additional types.

And nothing mentioned here has made any change to that.

The only issue that Thaddy is for some obscure reason mixing into this thread is, that there is an type-alias "cbool" (in unit ctypes) which was reviewed for being changed to alias another type than it has aliased before. (follow the link that Thaddy posted).

That "cbool" issue has not affected the bug of the original post.

[Thaddy]

Afaik there are API calls (kernel, etc) that may return "boolean", but with -1 or even just non-zero for true.

That is the reason FreePascal supports so many alternative Bool syntax too.
Boolean in itself is reserved for Pascal and either 0 or 1.
https://www.freepascal.org/docs-html/prog/progsu156.html#:~:text=The%20Boolean%20type%20is%20stored%20as%20a%20byte,and%20a%20longbool%20is%20stored%20as%20a%20longint.
Actually there are more types than in the docs, but Boolean is reserved to Pascal and can be used in other languages that define any Bool as being 0 or 1, like clang does.
In C it is common that a Bool true value is defined as not zero, usually a longBool and FreePascal supports that provided the right Bool type is chosen.
It is not that difficult. The whole discussion is fruitless and some nitwit decided to change the behavior just for some foreign library. He should have known - a lot - better!
Current trunk behaves almost correct btw.  I think this was the bug that Gareth referred too...
This is the current state at any optimization level:

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

1. var
2.  a:Boolean;
3.  b:LongBool;
4.  c:WordBool;
5.  d:ByteBool;
6. begin
7.   writeln(low(a),Ord(Low(a)):3);   // correct
8.   writeln(high(a),Ord(High(a)):3); // correct
9.   writeln(low(b),Ord(Low(b)):3);   // correct
10.   writeln(high(b),Ord(High(b)):3); // correct
11.   writeln(low(c),Ord(Low(c)):3);   // correct
12.   writeln(high(c),Ord(High(c)):3); // NOT correct, should be 65535
13.   writeln(low(d),Ord(Low(d)):3);   // correct
14.   writeln(high(d),Ord(High(d)):3); // NOT correct, should be 255
15. end.

Observe the bytebool and wordbool, which both pretend that -1 can be higher than 0....
That is the reason I make such a fuzz about it.
I can't explain it better than that.
Mutilating the language is not a good thing.
Note that even with range checks ON -1 is higher than 0.

[Zoran]

Thaddy, didn't you say that the behaviour of Boolean (not WordBool or any other, but Boolean) changed? Now you are talking about something totally different.

In those other bool types, we should know well that the order is not reliable, we should never use the order if we use such type.

So, although I do agree that it is plain wrong to emulate false < true order with types where -1 is the value of true, this is totally minor problem to what you said previously.

[Thaddy]

No, it is the same thing: Boolean gets expanded to register size and ignores flags at higher optimizations. My examples in FPC and Clang are proof of that.
That is what started the issue in the first place.
Both issues are the same, but platform dependent (CPU), not OS dependent.
Everything but Intel is not affected as far as I know. (Arm works fine)

[Martin_fr]

No, it is the same thing: Boolean gets expanded to register size and ignores flags at higher optimizations. My examples in FPC and Clang are proof of that.
That is what started the issue in the first place.

And that is why AI keep giving wrong answers. They are trained based on wrong content found in the internet. Wrong content, such as the above statement.

[Martin_fr]

Just to give a few more details.

The bug in the initial post of the thread was caused by the peephole optimizer. The peephole optimizer is a kind of "replace certain patterns engine". It has no idea what is boolean, it has no idea how boolean is stored or handled. It just replace a sequence of asm statements, with a different sequence of asm statements, if both statement-sequences do the same.

As the bug was caused by a part of the compiler that neither knows, nor depends on what boolean is, the bug is not be related to how boolean is defined or handled.

[Thaddy]

Then can you explain away my examples? You can't. AI has nothing to do with that....

[Martin_fr]

Then can you explain away my examples? You can't. AI has nothing to do with that....

To much work. Sorry, not interested.

As I said:

1) the peephole optimizer has no idea about boolean. It has no idea about Pascal. You could throw any piece of asm into the peephole optimizer, and it would optimize that asm.
2) The issue in this thread was fixed by a fix to that peephole optimizer
3) Ergo, it can not be related to the compiles definition/understanding/handling of boolean.

So it does not matter what your examples show  (or don't show) about what happens with boolean.
At this point I haven't even bothered to check if your examples are correct. It simply doesn't affect the case.



If the compiler generates code like

Code: ASM  [Select][+][-]

1. mov rax, rbx
2. mov rcx, rdx

The order of those can be changed. And the peephole optimizer  might do that, if it results in faster/shorter code.

But

Code: ASM  [Select][+][-]

1. mov rax, rbx
2. mov rbx, rdx

relies on that order.
If the peephole optimizer changes that, it is wrong.

But in neither case it matters in any way what the original Pascal (or C, or any other language) code was. And if that language code does not matter, then it does not matter what "boolean" means in that language.
(that is, it does not matter for what the peephole optimizer does / and/or does wrong)

And as for you point (the correctness of which I have not verified ) "the expansion to full register" => that was not affected by the peephole optimizer. It happening (or not happening) was kept the same as it was in the asm that was feed into the peephole optimizer.  And yet, the issue is now fixed, with it still happening (or not happening) the same as it has before.

[Thaddy]

I fully understand the internals. Always did... You keep repeating yourself just as many times as I do.
Let's close it.
Bug is proven.

[rvk]

Bug is proven.

And it's the an open bugreport for it?

A separate one, not connected to some other issue which could cloud things.
Preferable with a patch 

[Thaddy]

Why a patch? simply revert.