# Why is 0 false?

This question may sound dumb, but why does `0` evaluates to `false` and any other [integer] value to `true` is most of programming languages?

# String comparison

Since the question seems a little bit too simple, I will explain myself a little bit more: first of all, it may seem evident to any programmer, but why wouldn't there be a programming language - there may actually be, but not any I used - where `0` evaluates to `true` and all the other [integer] values to `false`? That one remark may seem random, but I have a few examples where it may have been a good idea. First of all, let's take the example of strings three-way comparison, I will take C's `strcmp` as example: any programmer trying C as his first language may be tempted to write the following code:

``````if (strcmp(str1, str2)) { // Do something... }
``````

Since `strcmp` returns `0` which evaluates to `false` when the strings are equal, what the beginning programmer tried to do fails miserably and he generally does not understand why at first. Had `0` evaluated to `true` instead, this function could have been used in its most simple expression - the one above - when comparing for equality, and the proper checks for `-1` and `1` would have been done only when needed. We would have considered the return type as `bool` (in our minds I mean) most of the time.

Moreover, let's introduce a new type, `sign`, that just takes values `-1`, `0` and `1`. That can be pretty handy. Imagine there is a spaceship operator in C++ and we want it for `std::string` (well, there already is the `compare` function, but spaceship operator is more fun). The declaration would currently be the following one:

``````sign operator<=>(const std::string& lhs, const std::string& rhs);
``````

Had `0` been evaluated to `true`, the spaceship operator wouldn't even exist, and we could have declared `operator==` that way:

``````sign operator==(const std::string& lhs, const std::string& rhs);
``````

This `operator==` would have handled three-way comparison at once, and could still be used to perform the following check while still being able to check which string is lexicographically superior to the other when needed:

``````if (str1 == str2) { // Do something... }
``````

# Old errors handling

We now have exceptions, so this part only applies to the old languages where no such thing exist (C for example). If we look at C's standard library (and POSIX one too), we can see for sure that maaaaany functions return `0` when successful and any integer otherwise. I have sadly seen some people do this kind of things:

``````#define TRUE 0
// ...
if (some_function() == TRUE)
{
// Here, TRUE would mean success...
// Do something
}
``````

If we think about how we think in programming, we often have the following reasoning pattern:

``````Do something
Did it work?
Yes ->
That's ok, one case to handle
No ->
Why? Many cases to handle
``````

If we think about it again, it would have made sense to put the only neutral value, `0`, to `yes` (and that's how C's functions work), while all the other values can be there to solve the many cases of the `no`. However, in all the programming languages I know (except maybe some experimental esotheric languages), that `yes` evaluates to `false` in an `if` condition, while all the `no` cases evaluate to `true`. There are many situations when "it works" represents one case while "it does not work" represents many probable causes. If we think about it that way, having `0` evaluate to `true` and the rest to `false` would have made much more sense.

# Conclusion

My conclusion is essentially my original question: why did we design languages where `0` is `false` and the other values are `true`, taking in account my few examples above and maybe some more I did not think of?

Follow-up: It's nice to see there are many answers with many ideas and as many possible reasons for it to be like that. I love how passionate you seem to be about it. I originaly asked this question out of boredom, but since you seem so passionate, I decided to go a little further and ask about the rationale behind the Boolean choice for 0 and 1 on Math.SE :)

• `strcmp()` is no good example for true or false, as it returns 3 different values. And you will be surprised when you start using a shell, where 0 means true and anything else means false. May 15 '13 at 20:27
• @ott--: In Unix shells, 0 means success and non-zero means failure -- not quite the same thing as "true" and "false". May 15 '13 at 21:27
• @KeithThompson: In Bash (and other shells), "success" and "failure" really are the same as "true" and "false". Consider, for example, the statement `if true ; then ... ; fi`, where `true` is a command that returns zero and this tells `if` to run `...`. May 16 '13 at 5:12
• There are no booleans in hardware whatsoever, only binary numbers, and in most historical ISAs a non-zero number is considered as "true" in all the conditional branching instructions (unless they're using flags instead). So, the low level languages are by all means obliged to follow the underlying hardware properties. May 16 '13 at 8:44
• @MasonWheeler Having a boolean type doesn't imply anything. For example python does have a `bool` type but comparisons/if conditions etc. can have any return value. May 16 '13 at 12:10

`0` is `false` because they’re both zero elements in common semirings. Even though they are distinct data types, it makes intuitive sense to convert between them because they belong to isomorphic algebraic structures.

• `0` is the identity for addition and zero for multiplication. This is true for integers and rationals, but not IEEE-754 floating-point numbers: `0.0 * NaN = NaN` and `0.0 * Infinity = NaN`.

• `false` is the identity for Boolean xor (⊻) and zero for Boolean and (∧). If Booleans are represented as {0, 1}—the set of integers modulo 2—you can think of ⊻ as addition without carry and ∧ as multiplication.

• `""` and `[]` are identity for concatenation, but there are several operations for which they make sense as zero. Repetition is one, but repetition and concatenation do not distribute, so these operations don’t form a semiring.

Such implicit conversions are helpful in small programs, but in the large can make programs more difficult to reason about. Just one of the many tradeoffs in language design.

• Nice that you mentioned lists. (BTW, `nil` is both the empty list `[]` and the `false` value in Common Lisp; is there a tendency to merge identities from different data types?) You still have to explain why it is natural to consider false as an additive identity and true as a multiplicative identity and not the other way around. Isn't possible to consider `true` as the identify for `AND` and zero for `OR`? May 16 '13 at 7:58
• +1 for referring to similar identities. Finally an answer which doesn't just boil down to "convention, deal with it".
– l0b0
May 16 '13 at 9:20
• +1 for giving details of a concrete and very old maths in which this has been followed and long made sense May 16 '13 at 15:22
• This answer doesn't make sense. `true` is also the identity and the zero of semirings (Boolean and/or). There is no reason, appart convention, to consider `false` is closer to 0 than `true`. Nov 17 '15 at 16:08
• @TonioElGringo: The difference between true and false is the difference between XOR and XNOR. One can form isomorphic rings using AND/XOR, where true is the multiplicative identity and false the additive one, or with OR and XNOR, where false is the multiplicative identity and true is the additive one, but XNOR is not usually regarded as a common fundamental operation the way XOR is. May 9 '17 at 17:10

Because the math works.

``````FALSE OR TRUE is TRUE, because 0 | 1 is 1.

... insert many other examples here.
``````

Traditionally, C programs have conditions like

``````if (someFunctionReturningANumber())
``````

rather than

``````if (someFunctionReturningANumber() != 0)
``````

because the concept of zero being equivalent to false is well-understood.

• The languages are designed like that because the math makes sense. That came first. May 15 '13 at 19:57
• @Morwenn, it goes back to the 19th century and George Boole. People have been representing False as 0 and True as !0 for longer than there have been computers. May 15 '13 at 20:03
• I don't see why the math doesn't work the other way if you merely change all of the definitions so that AND is + and OR is *. May 15 '13 at 21:49
• Exactly: the math works both ways and the answer to this question seems to be that it is purely conventional. May 15 '13 at 21:51
• @Robert It'd be great if you could spell out the "mathematical underpinnings" in your post. May 15 '13 at 21:59

As others have said, the math came first. This is why 0 is `false` and 1 is `true`.

Which math are we talking about? Boolean algebras which date from the mid 1800s, long before digital computers came along.

You could also say that the convention came out of propositional logic, which even older than boolean algebras. This is the formalization of a lot of the logical results that programmers know and love (`false || x` equals `x`, `true && x` equals `x` and so on).

Basically we're talking about arithmetic on a set with two elements. Think about counting in binary. Boolean algebras are the origin of this concept and its theoretical underpinning. The conventions of languages like C are just a straightforward application.

• You could, for sure. But keeping it the "standard" way fits in well with general arithmetic (0 + 1 = 1, not 0 + 1 = 0). May 15 '13 at 21:46
• Yes, but you would presumably write AND with + and OR with * if you reversed the definitions too. May 15 '13 at 21:47
• The math didn't come first. Math recognized that 0 and 1 form a field, in which AND is like multiplication and OR is like addition.
– Kaz
May 16 '13 at 0:57
• @Kaz: But {0, 1} with OR and AND does not form a field. May 16 '13 at 11:20
• It bothers me a little that more answers and comments say that `true = 1`. That's not quite exact, because `true != 0` which is not exactly the same. One reason (not the only one) why one should avoid comparisons like `if(something == true) { ... }`. Nov 12 '13 at 20:07

I thought this had to do with the "inheritance" from electronics, and also boolean algebra, where

• `0` = `off`, `negative`, `no`, `false`
• `1` = `on`, `positive`, `yes`, `true`

strcmp returns 0 when strings are equal has to do with its implementation, since what it actually does is to calculate the "distance" between the two strings. That 0 also happens to be considered false is just a coincidence.

returning 0 on success makes sense because 0 in this case is used to mean no error and any other number would be an error code. Using any other number for success would make less sense since you only have a single success code, while you can have several error codes. You use "Did it work?" as the if statement expression and say 0=yes would make more sense, but the expression is more correctly "Did anything go wrong?" and then you see that 0=no makes a lot of sense. Thinking of `false/true` doesn't really make sense here, as it's actually `no error code/error code`.

• Haha, you are the first one to state the return error question explicitely. I already knew I interpreted it my own way and and it could by asked the other way, but you're the first to explicitely express it (out of the many answers and comments). Actually, I wouldn't say that one or the other way makes no sense, but more that both make sense in different ways :) May 16 '13 at 11:11
• Actually I'd say `0` for `success/no error` is the only thing that makes sense when other integers represent error codes. That `0` also happens to represent `false` in other cases doesn't really matter, since we aren't talking about true or false here at all ;) May 16 '13 at 12:09
• I had the same idea so i upped May 17 '13 at 12:49
• Your point about `strcmp()` calculating the distance is quite good. If it had been called `strdiff()` then `if (!strdiff())` would be very logical. Jul 10 '14 at 21:53
• "electronics [...] where 0 = [...] false, 1 = [...] true" - even in electronics, this is only a convention, and isn't the only one. We call this positive logic, but you can also use negative logic, where a positive voltage indicates false and negative indicates true. Then, the circuit you'd use for AND becomes OR, OR becomes AND, and so on. Due to De Morgan's law, it all ends up being equivalent. Sometimes, you'll find part of an electronic circuit implemented in negative logic for convenience, at which point the names of the signals in that part are noted with a bar above them. Jul 21 '18 at 1:34

As explained in this article, the values `false` and `true` should not be confused with the integers 0 and 1, but may be identified with the elements of the Galois field (finite field) of two elements (see here).

A field is a set with two operations that satisfy certain axioms.

The symbols 0 and 1 are conventionally used to denote the additive and multiplicative identities of a field because the real numbers are also a field (but not a finite one) whose identities are the numbers 0 and 1.

The additive identity is the element 0 of the field, such that for all x:

``````x + 0 = 0 + x = x
``````

and the multiplicative identity is the element 1 of the field, such that for all x:

``````x * 1 = 1 * x = x
``````

The finite field of two elements has only these two elements, namely the additive identity 0 (or `false`), and the multiplicative identity 1 (or `true`). The two operations of this field are the logical XOR (+) and the logical AND (*).

Note. If you flip the operations (XOR is the multiplication and AND is the addition) then the multiplication is not distributive over addition and you do not have a field any more. In such a case you have no reason to call the two elements 0 and 1 (in any order). Note also that you cannot choose the operation OR instead of XOR: no matter how you interpret OR / AND as addition / multiplication, the resulting structure is not a field (not all inverse elements exist as required by the field axioms).

Regarding the C functions:

• Many functions return an integer that is an error code. 0 means NO ERROR.
• Intuitively, the function `strcmp` computes the difference between two strings. 0 means that there is no difference between two strings, i.e. that two strings are equal.

The above intuitive explanations can help to remember the interpretation of the return values, but it is even easier to just check the library documentation.

• +1 for showing that if you arbitrarily swap these, the maths no longer work out. May 16 '13 at 15:25
• Flipped: Given a field with two elements and operations * and +, we identify True with 0 and False with 1. We identify OR with * and XOR with +. May 17 '13 at 5:48
• You will find that both of these identifications are done over the same field and both are consistent with the rules of Boolean logic. Your note is unfortunately incorrect :) May 17 '13 at 5:49
• If you assume that True = 0, and XOR is +, then True must be the identity for XOR. But it is not because True XOR True = False. Unless you redefine the operation XOR on True so that True XOR True = True. Then of course your construction works because you have just renamed things (in any mathematical structure you can always successfully make a name permutation and get an isomorphic structure). On the other hand, if you let True, False and XOR have their usual meaning, then True XOR True = False and True cannot be the additive identity, i.e. True cannot be 0. May 17 '13 at 7:30
• @Giorgio: I corrected my construction per your comment in my last comment… May 17 '13 at 7:30

You should consider that alternative systems can also be acceptable design decisions.

### Shells: 0 exit status is true, non-zero is false

The example of shells treating a 0 exit status as true has already been mentioned.

``````\$ ( exit 0 ) && echo "0 is true" || echo "0 is false"
0 is true
\$ ( exit 1 ) && echo "1 is true" || echo "1 is false"
1 is false
``````

The rationale there is that there is one way to succeed, but many ways to fail, so using 0 as the special value meaning "no errors" is pragmatic.

### Ruby: 0 is just like any other number

Among "normal" programming languages, there are some outliers, such as Ruby, that treat 0 as a true value.

``````\$ irb
irb(main):001:0> 0 ? '0 is true' : '0 is false'
=> "0 is true"
``````

The rationale is that only `false` and `nil` should be false. For many Ruby novices, it's a gotcha. However, in some cases, it's nice that 0 is treated just like any other number.

``````irb(main):002:0> (pos = 'axe' =~ /x/) ? "Found x at position #{pos}" : "x not found"
=> "Found x at position 1"
irb(main):003:0> (pos = 'xyz' =~ /x/) ? "Found x at position #{pos}" : "x not found"
=> "Found x at position 0"
irb(main):004:0> (pos = 'abc' =~ /x/) ? "Found x at position #{pos}" : "x not found"
``````

However, such a system only works in a language that is able to distinguish booleans as a separate type from numbers. In the earlier days of computing, programmers working with assembly language or raw machine language had no such luxuries. It is probably just natural to treat 0 as the "blank" state, and set a bit to 1 as a flag when the code detected that something happened. By extension, the convention developed that zero was treated as false, and non-zero values came to be treated as true. However, it doesn't have to be that way.

### Java: Numbers cannot be treated as booleans at all

In Java, `true` and `false` are the only boolean values. Numbers are not booleans, and cannot even be cast into booleans (Java Language Specification, Sec 4.2.2):

There are no casts between integral types and the type `boolean`.

That rule just avoids the question altogether — all boolean expressions have to be explicitly written in the code.

• Rebol and Red both treat 0-valued INTEGER! values as true, and have a separate NONE! type (with only one value, NONE) treated as conditional false in addition to LOGIC! false. I've found significant frustration in trying to write JavaScript code that treats 0 as false; it is an incredibly clunky decision for a dynamically-typed language. If you want to test something that can be null or 0 you wind up having to write `if (thing === 0)`, that is just not cool. Apr 10 '14 at 20:52
• @HostileFork I don't know. I find that it makes sense that `0` is `true` (as every other integer) in a dynamic language. I sometimes happened to catch a `0` when trying to catch `None` in Python, and that can sometimes be pretty hard to spot. Apr 10 '14 at 21:22
• Ruby is not an outlier. Ruby takes this from Lisp (Ruby is even secretly called "MatzLisp"). Lisp is a mainstream language in computer science. Zero is also just a true value in the POSIX shell, because it's a piece of text: `if [ 0 ] ; then echo this executes ; fi`. The false data value is an empty string, and a testable falsehood is a failed termination status of a command, which is represented by a non-zero.
– Kaz
Jan 22 '15 at 19:42

String comparisons

The same holds for many sorts of comparisons, actually. Such comparisons compute a distance between two objects. When the objects are equal, the distance is minimal. So when the "comparison succeeds", the value is 0. But really, the return value of `strcmp` is not a boolean, it is a distance, and that what traps unaware programmers doing `if (strcmp(...)) do_when_equal() else do_when_not_equal()`.

In C++ we could redesign `strcmp` to return a `Distance` object, that overrides `operator bool()` to return true when 0 (but you would then be bitten by a different set of problems). Or in plain C just have a `streq` function that returns 1 when strings are equal, and 0 otherwise.

API calls/program exit code

Here you care about the reason something went wrong, because this will drive the decisions up on error. When things succeed, you don't want to know anything in particular - your intent is realized. The return value must therefore convey this information. It is not a boolean, it is an error code. The special error value 0 means "no error". The rest of the range represent locally meaningful errors you have to deal with (including 1, which often means "unspecified error").

General case

This leaves us with the question: why are boolean values `True` and `False` commonly represented with 1 and 0, respectively?

Well, besides the subjective "it feels better this way" argument, here are a few reasons (subjective as well) I can think of:

• electrical circuit analogy. The current is ON for 1s, and OFF for 0s. I like having (1,Yes,True,On) together, and (0,No,False,Off), rather than another mix

• memory initializations. When I `memset(0)` a bunch of variables (be them ints, floats, bools) I want their value to match the most conservative assumptions. E.g. my sum is initally 0, the predicate is False, etc.

Maybe all these reasons are tied to my education - if I had been taught to associate 0 with True from the beginning, I would go for the other way around.

• Actually there is at least one programming language that treats 0 as true. The unix shell. May 16 '13 at 10:55
• +1 for addressing the real issue: Most of Morwenn's question isn't about `bool` at all. May 17 '13 at 14:02
• @dan04 It is. The whole post is about the rationale behind the choice of the cast from `int` to `bool` in many programming languages. The comparison and error gestion stuff are just examples of places where casting it another way than the one it's currently done would have make sense. May 21 '13 at 6:40

From a high-level perspective, you're talking about three quite different data types:

1. A boolean. The mathematical convention in Boolean algebra is to use 0 for `false` and 1 for `true`, so it makes sense to follow that convention. I think this way also makes more sense intuitively.

2. The result of comparison. This has three values: `<`, `=` and `>` (notice that none of them is `true`). For them it makes sense to use the values of -1, 0 and 1, respectively (or, more generally, a negative value, zero and a positive value).

If you want to check for equality and you only have a function that performs general comparison, I think you should make it explicit by using something like `strcmp(str1, str2) == 0`. I find using `!` in this situation confusing, because it treats a non-boolean value as if it was a boolean.

Also, keep in mind that comparison and equality don't have to be the same thing. For example, if you order people by their date of birth, `Compare(me, myTwin)` should return `0`, but `Equals(me, myTwin)` should return `false`.

3. The success or failure of a function, possibly also with details about that success or failure. If you're talking about Windows, then this type is called `HRESULT` and a non-zero value doesn't necessarily indicate failure. In fact, a negative value indicates failure and non-negative success. The success value is very often `S_OK = 0`, but it can also be for example `S_FALSE = 1`, or other values.

The confusion comes from the fact that three logically quite different data types are actually represented as a single data type (an integer) in C and some other languages and that you can use integer in an condition. But I don't think it would make sense to redefine boolean to make using some non-boolean types in conditions simpler.

Also, consider another type that's often used in a condition in C: a pointer. There, it's natural to treat a `NULL`-pointer (which is represented as `0`) as `false`. So following your suggestion would also make working with pointers more difficult. (Though, personally, I prefer explicitly comparing pointers with `NULL`, instead of treating them as booleans.)

Zero can be false because most CPU's have a ZERO flag that can be used to branch. It saves a compare operation.

Lets see why.

Some psuedocode, as the audience probably don't read assembly

c- source simple loop calls wibble 10 times

``````for (int foo =10; foo>0; foo-- ) /* down count loop is shorter */
{
wibble();
}
``````

some pretend assembly for that

``````0x1000 ld a 0x0a      'foo=10
0x1002 call 0x1234    'call wibble()
0x1005 dec a          'foo--
0x1006 jrnz -0x06      'jump back to 0x1000 if not zero
0x1008
``````

c- source another simple loop calls wibble 10 times

``````for (int foo =0; foo<10; foo-- ) /* up count loop is longer  */
{
wibble();
}
``````

some pretend assembly for this case

``````0x1000 ld a 0x00      'foo=0
0x1002 call 0x1234    'call wibble()
0x1005 dec a          'foo--
0x1006 cmp 0x0a       'compare foo to 10 ( like a subtract but we throw the result away)
0x1008 jrns -0x08      'jump back to 0x1000 if compare was negative
0x100a
``````

some more c source

``````int foo=10;
if ( foo ) wibble()
``````

and the assembly

``````0x1000 ld a 0x10
0x1002 jz 0x3
0x1004 call 0x1234
0x1007
``````

see how short that is ?

some more c source

``````int foo=10;
if ( foo==0 ) wibble()
``````

and the assembly (lets assume a marginally smart compiler that can replace ==0 with no compare)

``````0x1000 ld a 0x10
0x1002 jz 0x3
0x1004 call 0x1234
0x1007
``````

Now lets try a convention of true=1

some more c source #define TRUE 1 int foo=TRUE; if ( foo==TRUE ) wibble()

and the assembly

``````0x1000 ld a 0x1
0x1002 cmp a 0x01
0x1004 jz 0x3
0x1006 call 0x1234
0x1009
``````

see how short the case with nonzero true is ?

Really early CPU's had small sets of flags attached to the Accumulator.

To check if a>b or a=b generally takes a compare instruction.

• Unless B is either ZERO - in which case the ZERO flag is set Implemented as a simple logical NOR or all bits in the Accumulator.
• Or NEGATIVE in which just use the "sign bit" i.e. the most significant bit of the Accumulator if you are using two's complement arithmetic. (Mostly we do)

Lets restate this. On some older CPU's you did not have to use a compare instruction for accumulator equal to ZERO, or accumulator less than zero.

Now do you see why zero might be false?

Please note this is psuedo-code and no real instruction set looks quite like this. If you know assembly you know I'm simplifying things a lot here. If you know anything about compiler design, you didn't need to read this answer. Anyone who knows anything about loop unrolling or branch prediction, the advanced class is down the hall in room 203.

• Your point is not well made here because for one thing `if (foo)` and `if (foo != 0)` should generate the same code, and secondly, you're showing that the assembly language you're using in fact has explicit boolean operands and tests for them. For instance `jz` means `jump if zero`. In other words `if (a == 0) goto target;`. And the quantity is not even being tested directly; the condition is converted its a boolean flag which is stored in a special machine word. It's actually more like `cpu.flags.zero = (a == 0); if (cpu.flags.zero) goto target;`
– Kaz
May 16 '13 at 17:02
• No Kaz, the older CPU's did not work like that. The jz/jnz can be performed without doing a comparison instruction. Which was kind of the point of my whole post really. May 19 '13 at 2:04
• I didn't write anything about a comparison instruction.
– Kaz
May 19 '13 at 2:35
• Can you cite a processor that has a `jz` instruction but no `jnz`? (or any other asymmetric set of conditional instructions) Nov 9 '16 at 16:58

There are a lot of answers that suggest that correspondance between 1 and true is necessitated by some mathematical property. I can't find any such property and suggest it is purely historical convention.

Given a field with two elements, we have two operations: addition and multiplication. We can map Boolean operations on this field in two ways:

Traditionally, we identify True with 1 and False with 0. We identify AND with * and XOR with +. Thus OR is saturating addition.

However, we could just as easily identify True with 0 and False with 1. Then we identify OR with * and XNOR with +. Thus AND is saturating addition.

• If you had followed the link on wikipedia you could have found that the concept of a boolean algebra is closed related with that of a Galois field of two elements (en.wikipedia.org/wiki/GF%282%29). The symbols 0 and 1 are conventionally used to denote the additive and multiplicative identities, respectively, because the real numbers are also a field whose identities are the numbers 0 and 1. May 15 '13 at 22:08
• @NeilG I think Giorgio is trying to say it's more than just a convention. 0 and 1 in boolean algebra are basically the same as 0 and 1 in GF(2), which behave almost the same as 0 and 1 in real numbers with regards to addition and multiplication. May 15 '13 at 23:47
• @svick: No, because you can simply rename multiplication and saturating addition to be OR and AND and then flip the labels so that 0 is True and 1 is False. Giorgio is saying that it was a convention of Boolean logic, which was adopted as a convention of computer science. May 16 '13 at 0:49
• @Neil G: No, you cannot flip + and * and 0 and 1 because a field requires distributivity of multiplication over addition (see en.wikipedia.org/wiki/Field_%28mathematics%29), but if you set + := AND and * := XOR, you get T XOR (T AND F) = T XOR F = T, whereas (T XOR T) AND (T XOR F) = F AND T = F. Therefore by flipping the operations and the identities you do not have a field any more. So IMO defining 0 and 1 as the identities of an appropriate field seems to capture false and true pretty faithfully. May 16 '13 at 1:08
• @giorgio: I have edited the answer to make it obvious what is going on. May 17 '13 at 5:55

Strangely, zero is not always false.

In particular, the Unix and Posix convention is to define `EXIT_SUCCESS` as 0 (and `EXIT_FAILURE` as 1). Actually it is even a standard C convention!

So for Posix shells and exit(2) syscalls, 0 means "successful" which intuitively is more true than false.

In particular, the shell's `if` wants a process return `EXIT_SUCCESS` (that is 0) to follow its "then" branch!

In Scheme (but not in Common Lisp or in MELT) 0 and nil (i.e. `()` in Scheme) are true, since the only false value is `#f`

I agree, I am nitpicking!

C is used for low-level programming close to hardware, an area in which you sometimes need to shift between bitwise and logical operations, on the same data. Being required to convert a numeric expression to boolean just to perform a test would clutter up the code.

You can write things like:

``````if (modemctrl & MCTRL_CD) {
/* carrier detect is on */
}
``````

rather than

``````if ((modemctrl & MCTRL_CD) != 0) {
/* carrier detect is on */
}
``````

In one isolated example it's not so bad, but having to do that will get irksome.

Likewise, converse operations. It's useful for the result of a boolean operation, like a comparison, to just produce a 0 or 1: Suppose we want to set the third bit of some word based on whether `modemctrl` has the carrier detect bit:

``````flags |= ((modemctrl & MCTRL_CD) != 0) << 2;
``````

Here we have to have the `!= 0`, to reduce the result of the biwise `&` expression to `0` or `1`, but because the result is just an integer, we are spared from having to add some annoying cast to further convert boolean to integer.

Even though modern C now has a `bool` type, it still preserves the validity of code like this, both because it's a good thing, and because of the massive breakage with backward compatibility that would be caused otherwise.

Another exmaple where C is slick: testing two boolean conditions as a four way switch:

``````switch (foo << 1 | bar) {  /* foo and bar booleans are 0 or 1 */
case 0: /* !foo && !bar */
break;
case 1: /* !foo && bar */
break;
case 2: /* foo && !bar */
break;
case 3: /* foo && bar */
break;
}
``````

You could not take this away from the C programmer without a fight!

Lastly, C sometimes serves as a kind of high level assembly language. In assembly languages, we also do not have boolean types. A boolean value is just a bit or a zero versus nonzero value in a memory location or register. An integer zero, boolean zero and the address zero are all tested the same way in assembly language instruction sets (and perhaps even floating point zero). Resemblance between C and assembly language is useful, for instance when C is used as the target language for compiling another language (even one which has strongly typed booleans!)

A boolean or truth value only has 2 values. True and false.

These should not be represented as integers, but as bits (0 and 1).

Saying any other integer beside 0 or 1 is not false is a confusing statement. Truth tables deal with truth values, not integers.

From a truth value prospective, -1 or 2 would break all truth tables and any boolean logic assoicated with them.

• 0 AND -1 == ?!
• 0 OR 2 == ?!

Most languages usually have a `boolean` type which when cast to a number type such as integer reveals false to be cast as a integer value of 0.

• 0 AND -1 == whatever boolean value you cast them to. That's what my question is about, why casting them to `TRUE` or `FALSE`. Never did I say - maybe I did, but it was not intended - integers were true or false, I asked about why they do evaluate to whichever when casted to boolean. May 15 '13 at 21:25

Ultimately, you are talking about breaking the core language because some APIs are crappy. Crappy APIs are not new, and you can't fix them by breaking the language. It is a mathematical fact that 0 is false and 1 is true, and any language which does not respect this is fundamentally broken. The three-way comparison is niche and has no business having it's result implicitly convert to `bool` since it returns three possible results. The old C APIs simply have terrible error handling, and are also hamstrung because C does not have the necessary language features to not have terrible interfaces.

Note that I am not saying that for languages which do not have implicit integer->boolean conversion.

• "It is a mathematical fact that 0 is false and 1 is true" Erm. May 15 '13 at 19:55
• Can you cite a reference for your "mathematical fact that 0 is false and 1 is true"? Your answer sounds dangerously like a rant. May 15 '13 at 19:57
• It's not a mathematical fact, but it's been a mathematical convention since the 19th century. May 15 '13 at 20:06
• Boolean algebra is represented by a finite field in which 0 and 1 are the identity elements for operations that resemble additon and multiplication. Those operations are, respectively, OR and AND. In fact, boolean algebra is written much like normal algebra where juxtaposition denotes AND, and the `+` symbol denotes OR. So for instance `abc + a'b'c` means `(a and b and c) or (a and (not b) and (not c))`.
– Kaz
May 16 '13 at 1:04