5 ms·

There is a concrete advantage to using a scheme where 0 is true and all other values are false: error codes. True means the operation succeeded correctly, or fa

There is a concrete advantage to using a scheme where 0 is true and all other values are false: error codes. True means the operation succeeded correctly, or false because of insufficient permissions, false because there file doesn't exist, false because of io error, false because of timeout etc. bash uses this scheme. However, this ship has sailed for general purpose programming languages. 0 is false, all other values are interpreted as true, operations that create a bool create 1. As you say, that's just how the world works. False = ~0 is just zany though.

JoshTriplett 7y ago
> There is a concrete advantage to using a scheme where 0 is true and all other values are false: error codes. True means the operation succeeded correctly, or false because of insufficient permissions, false because there file doesn't exist, false because of io error, false because of timeout etc. bash uses this scheme. That works perfectly fine if you write the type as an integer type and define 0 as "no error". You can't call that a C "bool" though.
- deleted 7y ago
  [deleted]
- nwallin 7y ago
  > You can't call that a C "bool" though. Correct. It was not my intent to imply otherwise. Like the person I replied to and I reiterated, that ship has sailed.
- fluffything 7y ago
  > You can't call that a C "bool" though. In hardware, C _Bool is just an scalar integer type (1 byte wide almost everywhere these days). If you define 0 for false, and true otherwise, you can emit much better machine code for all scalar comparisons. For example, when doing scalar == 0 or scalar != 0 (e.g. in null pointer checks) the result is always the scalar itself. The test is a nop, and with "branch on non-zero" instruction, you can just directly branch. If you define true to some value, you need to actually test whether the scalar is zero, and give it some other value otherwise. That goes from zero instructions to often two instructions (e.g. if the hardware comparison returns 0xffff and you need to convert that to 1).
phkahler 7y ago
Just change your interpretation of 0 for a return value. It does not mean success, it mean there was no error. Let's not confuse error codes (enums) for booleans because they arent.
jws 7y ago
Perhaps the type you want would be called “status” instead of bool. Zero meaning success, a few bits encoding severity, and the rest available to identify specifically the error. You would then have a macro or inline called “success” to convert it to a Boolean for flow control. Welcome to VMS!

JoshTriplett 7y ago

> There is a concrete advantage to using a scheme where 0 is true and all other values are false: error codes. True means the operation succeeded correctly, or false because of insufficient permissions, false because there file doesn't exist, false because of io error, false because of timeout etc. bash uses this scheme. That works perfectly fine if you write the type as an integer type and define 0 as "no error". You can't call that a C "bool" though.

deleted 7y ago
[deleted]
nwallin 7y ago
> You can't call that a C "bool" though. Correct. It was not my intent to imply otherwise. Like the person I replied to and I reiterated, that ship has sailed.
fluffything 7y ago
> You can't call that a C "bool" though. In hardware, C _Bool is just an scalar integer type (1 byte wide almost everywhere these days). If you define 0 for false, and true otherwise, you can emit much better machine code for all scalar comparisons. For example, when doing scalar == 0 or scalar != 0 (e.g. in null pointer checks) the result is always the scalar itself. The test is a nop, and with "branch on non-zero" instruction, you can just directly branch. If you define true to some value, you need to actually test whether the scalar is zero, and give it some other value otherwise. That goes from zero instructions to often two instructions (e.g. if the hardware comparison returns 0xffff and you need to convert that to 1).

phkahler 7y ago

Just change your interpretation of 0 for a return value. It does not mean success, it mean there was no error. Let's not confuse error codes (enums) for booleans because they arent.

jws 7y ago

Perhaps the type you want would be called “status” instead of bool. Zero meaning success, a few bits encoding severity, and the rest available to identify specifically the error. You would then have a macro or inline called “success” to convert it to a Boolean for flow control. Welcome to VMS!