Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not sure I get you - "not 0" is a more predicable value than a certain number, isn't it?


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.


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.


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.)


-1 isn't even a bad choice, since that's basically using 0xFF for true and 0x00 for false. The weirdness is the fact that you're converting a binary value to a signed integer.


This goes all the way to early BASIC, and it's signed because the language didn't have any unsigned numbers to begin with.

The main reason for this particular arrangement is that, so long as you can rely on truth being represented as -1 - i.e. all bits set - bitwise operators double as logical ones. Thus BASIC would have NOT, AND, OR, XOR, IMP, EQV all operating bitwise but mostly used for Booleans in practice (it misses short-circuiting, but languages of that era rarely defaulted to it).


If you can rely on truth being represented as 1 (or 3, fwiw) the same bitwise operations work fine.


NOT doesn't


A lot of the time variables will be in registers. And registers are basically ints. That would be my guess for why many things are ints that could fit in less space.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: