System.LongBool
24 comments
·October 22, 2025kevincox
> Note: The ByteBool, WordBool, and LongBool types exist to provide compatibility with other languages and operating system libraries.
Which makes sense. So these are really only intended to be used for FFI, not internal Delphi code. If you are bridging from C where bools are a byte you want to determine how you handle the other values.
I think the one thing missing is specifying what the True and False constants map to. It is implied that False maps to 0 by "A WordBool value is considered False when its ordinality is 0" but it doesn't suggest that True has a predictable value which would be important for FFI use cases.
Sharlin
And bools are definitely a byte only on "new" C standard versions (as in since C99), before that there was no boolean type and ints were often used. Thus, LongBool.
stefs
I'm not sure I get you - "not 0" is a more predicable value than a certain number, isn't it?
saurik
I presume this FFI goes in both directions; some APIs really want the value of a boolean to be 1 while others really want it to be "all 1s"/0xfff.../-1 because, internally, someone decided to do something silly and compare == or switch on TRUE.
masfuerte
The .Net runtime generates code that relies on bools being either 0 or 1. It's quite easy using interop to inadvertently set a bool to something else and this leads to very odd bugs where simple boolean expressions appear to be giving the wrong result.
(Tangentially, VB traditionally used -1 for true. VB.NET uses the same 0 or 1 internal representation for a bool as C# but if you convert a bool to a number in VB.NET it comes out as -1.)
kevincox
I'm talking about output. For sure, if I am reading this bool from FFI I want to have "not 0" be truthy. However if I am writing a bool to a FFI interface I want the value to be predictable (for example 1) rather than "some non-zero value".
Although this does open interesting cases where if you read a bool from one FFI interface and write to another it may have an unexpected value (ex 2). But I still think it is useful for the in-language conversions for example Boolean to LongBool and the True constant to have predictable values.
knodi123
I chuckled, but presumably it's useful for applications where you want data types to take up the same amount of space, like for matrices or database columns? Or maybe where you coerce different data types into boolean? The language offers WordBool and ByteBool too, so they're pretty consistent. And AFAIK, there aren't any languages where you can specifically allocate only a single bit for a single boolean.
nneonneo
You kind of can in C with bit size specifications on struct members, but you’ll still face the problem that C’s minimum alignment is one byte - so a struct containing a single 1-bit field will still occupy a byte in memory. However, it does let you “allocate” different bits within a byte for different member fields.
C++ has vector<bool>, which is supposed to be an efficient bit-packed vector of Booleans, but due to C++ constraints it doesn’t quite behave like a container (unlike other vector<T>s). Of course, if you make a vector<bool> of a single bit, that’s still going to occupy much more than one bit in memory.
There are plenty of hardware specification languages where it’s trivial to “allocate” one bit, but those aren’t allocating from the heap in a traditional sense. (Simulators for these languages will often efficiently pack the bits in memory, but that’s more of an implementation detail than a language guarantee).
1313ed01
Also in Free Pascal?
noir_lord
Amazes me that Embarcadero/Delphi is still going - it's been 25ish years since I wrote a line of Object Pascal, it was a very nice language in its day with an even nicer IDE.
mastax
Don’t they use int-size bools in Solaris? I think I remember seeing those in ZFS.
azhenley
I need some context… why?
dale_glass
It says it right there:
"Note: The ByteBool, WordBool, and LongBool types exist to provide compatibility with other languages and operating system libraries."
beyondCritics
Turns out that old versions of Visual C++ used their own typedef of bool as int: https://stackoverflow.com/questions/4897844/is-sizeofbool-de...
bobmcnamara
There were risc platforms with int sized bool, usually where one byte math wasn't in the instruction set.
bobmcnamara
In C, sizeof(bool) is implementation specific. Typical values are sizeof(char) and sizeof(int).
keketi
In case you need a lot more than two boolean values some day.
huflungdung
[dead]
spyrja
Next up: 64-bit booleans for the win!
nine_k
This reply was wrong, removed.
Please downvote it to oblivion.
p_l
Every major CPU ISA still in use can, in fact, address individual bytes (C and C++ standards even demand atomic access).
It's just inefficient, but sometimes needed (MMIO, inter-cpu visible byte changes, etc)
null
jonathrg
You can just make stuff up on this website
I assume this type is for compatibility with the 32-bit BOOL type on Windows. This is a common bugaboo when doing interoperability, as I think languages tend to define bool as a 8-bit value.
https://learn.microsoft.com/en-us/windows/win32/winprog/wind...
This must be a pretty slow news day for this to make the front page of Hacker News.