Bart van den Broek wrote:
Indeed I meant Ord(ByteBool(True)) = $FF and so on.
When I run this program in Delphi v7.1 (7.0 + patch)
program Project1;
{$APPTYPE CONSOLE}
procedure RunTest; var n : Integer; m : Integer; begin n := 42; m := 43; Writeln(ByteBool(n) = ByteBool(m)); Writeln(ByteBool(n) = ByteBool(42)); Writeln(ByteBool(n) = True); Writeln(Ord(ByteBool(True)));
Writeln(WordBool(n) = WordBool(m)); Writeln(WordBool(n) = WordBool(42)); Writeln(WordBool(n) = True); Writeln(Ord(WordBool(True)));
Writeln(LongBool(n) = LongBool(m)); Writeln(LongBool(n) = LongBool(42)); Writeln(LongBool(n) = True); Writeln(Ord(LongBool(True)));
Writeln(Pred(Boolean(False))); Writeln(Pred(ByteBool(False))); Writeln(Pred(WordBool(False))); Writeln(Pred(LongBool(False))); end;
begin RunTest; end.
I get this output (ignore extra empty lines i put in):
TRUE TRUE TRUE 255
TRUE TRUE TRUE 65535
TRUE TRUE TRUE -1
<gibberish> <gibberish> TRUE TRUE
Note the signedness of the Ord(LongBool(True)), probably due to the fact that Ord function is 32 bits integer.
BTW, is it really the Ord function in general? Does Ord applied to an unsigned 32 bit integer convert it to signed? If not (as I hope ;-), it seems to be not a property of the Ord function, but of the LongBool type (perhaps from times when Delphi didn't support unsigned 32 bit).
I guess being completely compatible here is not simple.
I really think so -- also considering The Chief's tests. Does anyone know if the different behaviour between Delphi 3/4 and 7 is documented? Otherwise we might just say Delphi's behaviour is not precisely defined in the first place ...
BTW, FPC's behaviour is also interesting, m and n are considered equal in ByteBool and WordBool, but not in LongBool.
Considering C compatibility, most C functions that expect a Boolean argument in an integer will probably accept any non-zero value as true, though the documented value is often (IMHO) 1, often via a #define TRUE 1 or such, rarely 0xff, 0xffff, 0xffffffff, -1 or such. This would suggest making Ord (FooBool (True)) always 1 (in accordance with FPC, and with general BP type-cast rules, but in contrast to Delphi).
Seeing these questions, I'd rather get rid of such types at all, if we didn't need them for Delphi compatibility ... :-(
Frank