Boolean type

[TRon]

It does, actually (another link in the page you gave): https://www.gnu-pascal.org/gpc/Boolean-_0028Intrinsic_0029.html#Boolean-_0028Intrinsic_0029

Well, sort of. It tells us how the compiler handles it/treats them (which differs from tp/fpc). It (at least ISO pascal, I'm  not too familiar with gnu) does not explicitly says anything about how these enumerated values are actually stored in memory. For all we know such boolean actually occupies 64 bits in memory or perhaps even 128 bits. And as long as the compiler treats them in a certain way, it does not matter. It should behave as a black box. This in contrast to the other in gnu pascal defined boolean types.

[440bx]

That example is truly bad. It might be (part of) why 440bx is so strongly against the ability to use typecasts on boolean. (Albeit, his arguments are still wrong, as they simple aren't true).

The drunk tree got in the way... bad, bad tree!  does that tree have a licence to drive ?...

Why would the compiler refuse an invalid typecast as it does with countless others ?... it's not a bug... good compiler for allowing nonsense.  That's strong typing for you... you want nonsense ?... no problem... it's your lucky day... FPC will allow it... and when it doesn't work... it's your fault...   Wonderful !!  (reminds me of the original implementation of C where undefined identifiers were simply assumed to be integers... why did they get rid of that wonderful feature... it was obviously the programmer's fault that the identifier had not been declared... obviously because it's the programmer who has to declare them!)

Unbelievable! 

[Khrys]

When explicit casting is involved, the compiler must not do any checking, that's the point of explicit casting. Explicit casting must not adjust bits in a variable, that's the one and only thing we can rely on.

About that...

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

1. Double(Some_Integer)
2. PChar(Some_AnsiString)
3. WideString(Some_AnsiString)

There is no consistency regarding casts in FPC -  Integer(Some_Double)  is forbidden, but the reverse works just fine; casts between string types in general laugh at this supposed principle.

Would it really kill the compiler to turn this:

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

1. mov eax, edi

...into this:

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

1. test edi, edi
2. setne al

...when casting to  Boolean? In the compiler's philosphy, casts involving more than just bit pattern reinterpretation seem to be perfectly fine (as demonstrated above). Why not reduce the attack surface of invalid-boolean-bit-pattern UB?
Reiterating what I've said before:

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.

[Joanna from IRC]

Is Boolean not an ordinal type? if so how can you type cast it at all? if it is an ordinal type boolean = (false,true)
why doesn't boolean type cast return error of invalid typecast for all numbers besides 0 or 1?
this seem like inconsistent behavior that should be fixed. is there a reason it isn't ?

[Zoran]

There is no consistency regarding casts in FPC -  Integer(Some_Double)  is forbidden,

Uh, It is indeed! Now I'm totally confused! What? Why?
And casting from Integer to Double seems to reintrpret the bits!!! Total mess, I can't believe this!

Would it really kill the compiler to turn this:

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

1. mov eax, edi

...into this:

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

1. test edi, edi
2. setne al

...when casting to  Boolean? In the compiler's philosphy, casts involving more than just bit pattern reinterpretation seem to be perfectly fine (as demonstrated above).

We really don't need this. The behaviour you want can be easily achieved by using "<> 0", there is no need for such casting. We need a reliable unsafe type casting.

But this "cast" from Integer to Double, which is not cast, but reinterpretation is a total mess! Allowing casting to mess with bits is just totally wrong.
Can we rely on anything???

[Zoran]

With type casting you are skipping the strong type system. That's it.

Just forget what I said, it seems that I had no idea what I was talking about.
I certainly don't understand the type casting, I got it totally wrong.
 

[Martin_fr]

There are 2 operations by the syntax: SomeType(SomeValue)

- typecasts
- conversion.

E.g. Int64(MyIntVar)
is a conversion. It will sign extend the value from 32 to 64 bit.

It is a bit of a pity that the same syntax does 2 different things.

[nanobit]

But this "cast" from Integer to Double

The double( int) bug fix is in newer versions.

[Zoran]

There are 2 operations by the syntax: SomeType(SomeValue)

- typecasts
- conversion.

E.g. Int64(MyIntVar)
is a conversion. It will sign extend the value from 32 to 64 bit.

It is a bit of a pity that the same syntax does 2 different things.

But in your example, although it extends 32-bit to 64-bit, the lower 32 bit value does not change.
Now I tried

Code: [Select]

Double(Int64Variable), which is same size, and the bits were reinterpreted! So, it is not about extending size, it actually changed the bits.

I don't get it. How does the compiler decide when it is a cast, and when it is a conversion? How do we know what to expect from the compiler - cast or conversion?

I haven't known about this conversion until now. I've always thought that we have assignment compatibility from Integer to Double, which serves the purpose quite well. And for assigning Double to Integer there is Trunc().

[Zoran]

But this "cast" from Integer to Double

The double( int) bug fix is in newer versions.

Uh, the bug is that in mode Delphi it behaves as cast, and in objfpc it behaves as conversion. But, if I understand well, the "fix" is that now the mode Delphi behaviour is "corrected", so that it no more casts, but converts the value!

Total mess, so we just can't use the "unsafe" cast safely.
Is this conversion behaviour documented anywhere? Not a word about it in https://www.freepascal.org/docs-html/ref/refse85.html#x147-17100012.5 page.

How can we tell when it is not a cast but a conversion? Why wasn't assignment compatibility of Integer to Double good enough?

[440bx]

there doesn't seem to be much sense in FPC's typecasting system.

For instance, in the following:

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

1.  
2. const
3.   ASignature = DWORD('abcd');    { it doesn't accept this }
4.   ASignature = DWORD('a');       { but it accepts this }
5.   ABoolean   = boolean('a');     { this is also acceptable, really ??? }
6.  
7. var
8.   ASignatureVar : DWORD;
9.   ABooleanVar   : boolean;
10.   ABoolean32Var : boolean32;
11.  
12. begin
13.   ASignatureVar := DWORD('abcd');   { it accepts this. ok for a var but not for a constant ? that makes a lot of sense ;-)  }
14.  
15.   ASignatureVar := DWORD('abcde');  { it doesn't accept this, which is good   }
16.  
17.   ASignatureVar := DWORD('a');      { it accepts this }
18.  
19.   ASignatureVar := DWORD('ab');     { it doesn't accept this, why not ? 'a' is fine but 'ab' isn't ? }
20.  
21.   ABooleanVar   := boolean('a');    { typecast a character into a boolean ... NO problem... LOL }
22.  
23.   ABoolean32Var := boolean32('abcd');  { another jewel }
24.  

Time to have some fun:

1. In a constant, you cannot typecast "abcd" into a DWORD but, you can do exactly that cast in a DWORD variable.

2. In a constant, you CAN typecast "a" into a DWORD.  Basically, DWORD is working like "ord"

3. typecasting "abcde" to a DWORD variable is not acceptable (which is good because of the size, i.e, the extra "e")

4. typecasting "a" to a DWORD variable is acceptable (that's questionable because the size isn't right but, seems like DWORD is sort of equal to "ord")

5. typecasting "ab" to a DWORD variable is NOT acceptable.  if it accepts "a" and "abcd" then why doesn't it accept "ab" and "abc" ????  It should zero pad the value just as it did when there was only "a". 

it looks like between "a" and "abcd" all there is, is, "undefined territory".

6. and there is no problem typecasting a character or character string to a boolean.  In FPC, booleans are 0, 1 and "abcd" and any other string that fits (never mind it's a string... that's "perfectly" fine... who could possibly expect a compiler for a strongly typed language to catch such an error ???)  Some strong type checking there!

[Zoran]

who could possibly expect a compiler for a strongly typed language to catch such an error ???)  Some strong type checking there!

Strongly typed language? When Pascal was typed that strongly, it rightfully earned the title of a toy language.

What strong type checking? Why would you expect type checking? Apart from not touching the bits in any way, the essential thing with casting is that no type checking should take place.
At least I've thought so until now, when I see that casting an integral value to double seems to behave same as simple assignment, the compiler converts the value, making casting totally useless.

When a programmer uses explicit type casting, he says to the compiler - do not attempt to check anything, I know what I'm doing and why I want to do so.
What else do you think casting can be useful for?

[440bx]

When a programmer uses explicit type casting, he says to the compiler - do not attempt to check anything, I know what I'm doing and why I want to do so.

You got that completely wrong.  Typecasting isn't "limitless" and that's quite obvious because there are plenty of typecasts the compiler rejects.  You really have to rethink that.

[Thaddy]

Actually he is right. Guaranteed correct casts use is and as.

[Zoran]

When a programmer uses explicit type casting, he says to the compiler - do not attempt to check anything, I know what I'm doing and why I want to do so.

You got that completely wrong.  Typecasting isn't "limitless" and that's quite obvious because there are plenty of typecasts the compiler rejects.  You really have to rethink that.

Okay, I'm moving away from casting, and I am going to use absolute directive or variant records to workaround casting.
But then, please tell me what can be the purpose of type casting? And why the documentation doesn't say anything about that sometimes you can just get conversion instead?