Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
22  
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. –  ott-- May 15 '13 at 20:27
36  
@ott--: In Unix shells, 0 means success and non-zero means failure -- not quite the same thing as "true" and "false". –  Keith Thompson May 15 '13 at 21:27
9  
@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 .... –  ruakh May 16 '13 at 5:12
10  
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. –  SK-logic May 16 '13 at 8:44
2  
@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. –  Bakuriu May 16 '13 at 12:10

14 Answers 14

up vote 61 down vote accepted

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.

share|improve this answer
    
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? –  Giorgio May 16 '13 at 7:58
1  
+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
2  
+1 for giving details of a concrete and very old maths in which this has been followed and long made sense –  Jimmy Hoffa May 16 '13 at 15:22
    
Boolean OR has no inverse. How does that form a ring? –  Siyuan Ren Sep 5 '13 at 3:09
    
I'm unclear whether the fact that they are isomorphic algebras is being proved or used as an assumption here. –  Andyz Smith Oct 5 '13 at 3:48

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.

share|improve this answer
12  
The languages are designed like that because the math makes sense. That came first. –  Robert Harvey May 15 '13 at 19:57
20  
@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. –  Charles E. Grant May 15 '13 at 20:03
8  
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 *. –  Neil G May 15 '13 at 21:49
5  
Exactly: the math works both ways and the answer to this question seems to be that it is purely conventional. –  Neil G May 15 '13 at 21:51
5  
@Robert It'd be great if you could spell out the "mathematical underpinnings" in your post. –  phant0m 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.

share|improve this answer
1  
You could, for sure. But keeping it the "standard" way fits in well with general arithmetic (0 + 1 = 1, not 0 + 1 = 0). –  joshin4colours May 15 '13 at 21:46
1  
Yes, but you would presumably write AND with + and OR with * if you reversed the definitions too. –  Neil G May 15 '13 at 21:47
3  
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
1  
@Kaz: But {0, 1} with OR and AND does not form a field. –  Giorgio May 16 '13 at 11:20
1  
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) { ... }. –  JensG 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.

share|improve this answer
    
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 :) –  Morwenn 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 ;) –  Svish May 16 '13 at 12:09
    
I had the same idea so i upped –  user60812 May 17 '13 at 12:49
1  
Your point about strcmp() calculating the distance is quite good. If it had been called strdiff() then if (!strdiff()) would be very logical. –  Kevin Cox Jul 10 at 21:53

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.

share|improve this answer
1  
+1 for showing that if you arbitrarily swap these, the maths no longer work out. –  Jimmy Hoffa May 16 '13 at 15:25
    
Original: Given the field with two elements and operations * and +, we identify True with 1 and False with 0. We identify AND with * and XOR with +. –  Neil G May 17 '13 at 5:48
1  
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 +. –  Neil G May 17 '13 at 5:48
1  
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 :) –  Neil G May 17 '13 at 5:49
    
@Neil G: I understand your construction now and I am trying to verify it. What I am missing is how True can be the identity of XOR since True XOR True = False. We both assume that True, False, and the operations AND, OR, NOT, XOR on these values are given, right? –  Giorgio May 17 '13 at 7:18

Before addressing the general case, we can discuss your counter examples.

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.

share|improve this answer
2  
Actually there is at least one programming language that treats 0 as true. The unix shell. –  Jan Hudec May 16 '13 at 10:55
    
+1 for addressing the real issue: Most of Morwenn's question isn't about bool at all. –  dan04 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. –  Morwenn May 21 '13 at 6:40

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"
=> "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.

share|improve this answer
    
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. –  HostileFork Apr 10 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. –  Morwenn Apr 10 at 21:22

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

share|improve this answer

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.

share|improve this answer
4  
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. –  Giorgio May 15 '13 at 22:08
1  
@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. –  svick May 15 '13 at 23:47
1  
@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. –  Neil G May 16 '13 at 0:49
1  
@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. –  Giorgio May 16 '13 at 1:08
1  
@giorgio: I have edited the answer to make it obvious what is going on. –  Neil G May 17 '13 at 5:55

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.

share|improve this answer
2  
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. –  Tim Williscroft May 19 '13 at 2:04
2  
I didn't write anything about a comparison instruction. –  Kaz May 19 '13 at 2:35

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

share|improve this answer

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.

share|improve this answer
    
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. –  Morwenn May 15 '13 at 21:25

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!

share|improve this answer

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.

share|improve this answer
1  
I'm not talking about changing or breaking anything. That's just some thoughts history of language design. –  Morwenn May 15 '13 at 19:55
10  
"It is a mathematical fact that 0 is false and 1 is true" Erm. –  R. Martinho Fernandes May 15 '13 at 19:55
9  
Can you cite a reference for your "mathematical fact that 0 is false and 1 is true"? Your answer sounds dangerously like a rant. –  Dan Pichelman May 15 '13 at 19:57
13  
It's not a mathematical fact, but it's been a mathematical convention since the 19th century. –  Charles E. Grant May 15 '13 at 20:06
1  
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

protected by World Engineer May 15 '13 at 22:36

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.