# Which numbers evaluate to true and false?

Discussion in 'C Programming' started by Paminu, Oct 4, 2005.

1. ### PaminuGuest

As I remember if(1) evaluates to true and all other numbers including 0
evaluate to false.

the C for dummies books and various other C programming books but nowhere
there is a mention on what a number in an if statement evaluates to.

Is this some kind of big secret?

Paminu, Oct 4, 2005

2. ### Christoph SchmidtGuest

Nearly. 0 evaluates to false and any other number to true (I am not completely

Cheers,
Chris

Paminu wrote:

> As I remember if(1) evaluates to true and all other numbers including 0
> evaluate to false.
>
> But where do I find out about this for sure?? I have looked through K&R, all
> the C for dummies books and various other C programming books but nowhere
> there is a mention on what a number in an if statement evaluates to.
>
> Is this some kind of big secret?

Christoph Schmidt, Oct 4, 2005

3. ### SkarmanderGuest

Paminu wrote:
> As I remember if(1) evaluates to true and all other numbers including 0
> evaluate to false.
>

No. if(1) is nothing. If you meant something like

if (1) {
...
}

That doesn't evaluate to anything; it's a statement.

The statements in the "if" branch will be executed if the test
expression evaluates to a non-zero value. Otherwise, the "else" branch
will be executed, if there is one.
if (x) {
...
}
is the same as
if (x != 0) {
...
}

So your statement actually gets it backwards: 0 is "false" (loosely
speaking, since C doesn't have a proper boolean type) and any non-zero
value is "true". But "false" and "true" don't exist as actual values. An
operator like != will yield either 0 or 1, so we could call those
"false" and "true", as long as we keep in mind that C is actually a bit
more liberal than that.

> But where do I find out about this for sure?? I have looked through K&R, all
> the C for dummies books and various other C programming books but nowhere
> there is a mention on what a number in an if statement evaluates to.
>

Probably because you're not reading them quite right. All books I've
read do address this issue, but not exactly in the way you're
interpreting it.

> Is this some kind of big secret?

Yes: C has no boolean type. But I wouldn't call it "big".

S.

Skarmander, Oct 4, 2005
4. ### Christopher Benson-ManicaGuest

Paminu <> wrote:

> As I remember if(1) evaluates to true and all other numbers including 0
> evaluate to false.

No. Expressions that compare equal to 0, including NULL pointers, are
"false". All others are "true".

> But where do I find out about this for sure?? I have looked through K&R, all
> the C for dummies books and various other C programming books but nowhere
> there is a mention on what a number in an if statement evaluates to.

It is on page 223 of my copy of K&R 2.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

Christopher Benson-Manica, Oct 4, 2005
5. ### Keith ThompsonGuest

Paminu <> writes:
> As I remember if(1) evaluates to true and all other numbers including 0
> evaluate to false.
>
> But where do I find out about this for sure?? I have looked through K&R, all
> the C for dummies books and various other C programming books but nowhere
> there is a mention on what a number in an if statement evaluates to.
>
> Is this some kind of big secret?

Not at all. See, for example, section 9 of the C FAQ.

BTW, here's what the standard says (my copy of K&R isn't handy):

In both forms, the first substatement is executed if the
expression compares unequal to 0. In the else form, the second
substatement is executed if the expression compares equal to 0. If
the first substatement is reached via a label, the second
substatement is not executed.

The phrase "both forms" refers to "if ( expression ) statement"
vs. "if (expression ) statement else statement".

--
Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Keith Thompson, Oct 4, 2005
6. ### Keith ThompsonGuest

Skarmander <> writes:
[...]
> Yes: C has no boolean type.

C99 has _Bool (called "bool" with "#include <stdbool.h>").

--
Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Keith Thompson, Oct 4, 2005
7. ### Christian BauGuest

In article <dhuo1f\$a2v\$-c.dk>, Paminu <>
wrote:

> As I remember if(1) evaluates to true and all other numbers including 0
> evaluate to false.
>
> But where do I find out about this for sure?? I have looked through K&R, all
> the C for dummies books and various other C programming books but nowhere
> there is a mention on what a number in an if statement evaluates to.

from many places, a search for "C Standard Final Draft" in google for
example came up with

http://www.ucalgary.ca/~bgwong/n869.pdf

This is NOT the C Standard, but it is reasonably close for many

http://www.ansi.org/

as far as I know for US\$18.

if (x)

gives exactly the same result as

if ((x) != 0)

x can be any number or any pointer. Therefore,

if (2) printf ("true"); else printf ("false");

will print "true" and not "false".

Christian Bau, Oct 4, 2005
8. ### SkarmanderGuest

Keith Thompson wrote:
> Skarmander <> writes:
> [...]
>
>>Yes: C has no boolean type.

>
>
> C99 has _Bool (called "bool" with "#include <stdbool.h>").
>

Pfff. I sort-of semi-deliberately overlooked that, but yes, you're quite
right.

S.

Skarmander, Oct 4, 2005
9. ### SkarmanderGuest

Skarmander wrote:
> Keith Thompson wrote:
>
>> Skarmander <> writes:
>> [...]
>>
>>> Yes: C has no boolean type.

>>
>>
>>
>> C99 has _Bool (called "bool" with "#include <stdbool.h>").
>>

> Pfff. I sort-of semi-deliberately overlooked that, but yes, you're quite
> right.
>

You know, for some reason the C99 bool really annoys me. *Now* they fix
things? Too late. Leave it alone. Introducing size_t to provide a new
level of abstraction was a good thing. But bool? Not worth the bother,
with the backwards compatibility tricks they have to pull.

It ticks me off because I'd *like* to use "real" booleans, but if that
means requiring a C99 compiler, then no thanks, it's not worth it.
Classic chicken and egg story.

S.

Skarmander, Oct 4, 2005
10. ### Keith ThompsonGuest

Christian Bau <> writes:
> In article <dhuo1f\$a2v\$-c.dk>, Paminu <>
> wrote:
>
>> As I remember if(1) evaluates to true and all other numbers including 0
>> evaluate to false.
>>
>> But where do I find out about this for sure?? I have looked through K&R, all
>> the C for dummies books and various other C programming books but nowhere
>> there is a mention on what a number in an if statement evaluates to.

>
> from many places, a search for "C Standard Final Draft" in google for
> example came up with
>
> http://www.ucalgary.ca/~bgwong/n869.pdf
>
> This is NOT the C Standard, but it is reasonably close for many
>
> http://www.ansi.org/
>
> as far as I know for US\$18.

You can also get n1124 from
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf>. This is
a draft of the *next* version of the standard (post-C99); it's
basically the C99 standard with a few corrections.

--
Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Keith Thompson, Oct 4, 2005
11. ### James McIninchGuest

Paminu wrote:

> As I remember if(1) evaluates to true and all other numbers including 0
> evaluate to false.

That would be 0 is false and all other true.

> all the C for dummies books and various other C programming books but
> nowhere there is a mention on what a number in an if statement evaluates
> to.
>
> Is this some kind of big secret?

No secret. Any C language reference will tell you:

http://www.lysator.liu.se/c/bwk-tutor.html#if

--

James McIninch, Oct 4, 2005
12. ### August KarlstromGuest

Skarmander wrote:
> Skarmander wrote:
>
>> Keith Thompson wrote:
>>
>>> Skarmander <> writes:
>>> [...]
>>>
>>>> Yes: C has no boolean type.
>>>
>>>
>>>
>>>
>>> C99 has _Bool (called "bool" with "#include <stdbool.h>").
>>>

>> Pfff. I sort-of semi-deliberately overlooked that, but yes, you're
>> quite right.
>>

>
> You know, for some reason the C99 bool really annoys me. *Now* they fix
> things? Too late. Leave it alone. Introducing size_t to provide a new
> level of abstraction was a good thing. But bool? Not worth the bother,
> with the backwards compatibility tricks they have to pull.
>
> It ticks me off because I'd *like* to use "real" booleans, but if that
> means requiring a C99 compiler, then no thanks, it's not worth it.
> Classic chicken and egg story.

The real virtue of the bool type is that it conveys more information
compared to an int used as a boolean type. You never need comments as
"non-zero if... and zero if...". You still need to know though that it
is really just an int and that zero is interpreted as `false' and
non-zero as `true'.

August

August Karlstrom, Oct 5, 2005
13. ### August KarlstromGuest

Skarmander wrote:
> Skarmander wrote:
>
>> Keith Thompson wrote:
>>
>>> Skarmander <> writes:
>>> [...]
>>>
>>>> Yes: C has no boolean type.
>>>
>>>
>>>
>>>
>>> C99 has _Bool (called "bool" with "#include <stdbool.h>").
>>>

>> Pfff. I sort-of semi-deliberately overlooked that, but yes, you're
>> quite right.
>>

>
> You know, for some reason the C99 bool really annoys me. *Now* they fix
> things? Too late. Leave it alone. Introducing size_t to provide a new
> level of abstraction was a good thing. But bool? Not worth the bother,
> with the backwards compatibility tricks they have to pull.

What backwards compatibility tricks?

August

August Karlstrom, Oct 5, 2005
14. ### SkarmanderGuest

August Karlstrom wrote:
> Skarmander wrote:
>
>> Skarmander wrote:
>>
>>> Keith Thompson wrote:
>>>
>>>> Skarmander <> writes:
>>>> [...]
>>>>
>>>>> Yes: C has no boolean type.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> C99 has _Bool (called "bool" with "#include <stdbool.h>").
>>>>
>>> Pfff. I sort-of semi-deliberately overlooked that, but yes, you're
>>> quite right.
>>>

>>
>> You know, for some reason the C99 bool really annoys me. *Now* they fix
>> things? Too late. Leave it alone. Introducing size_t to provide a new
>> level of abstraction was a good thing. But bool? Not worth the bother,
>> with the backwards compatibility tricks they have to pull.

>
>
> What backwards compatibility tricks?
>

Rather than just adding "bool", "true" and "false" to the language
(which would break many programs even if they use the "right"
definitions), we've got a new type called _Bool, and if you want to have
it named "bool", you #include <stdbool.h>. Which you'll always do,
unless of course you have to be compatible with an existing unit that
defines "bool".

That's what I call a backwards compatibility trick. (OK, so maybe it's
just one.) _Bool will also be the first keyword beginning with an
underscore.

I don't know. I'm sure it works and is a very practical solution. It's
still ugly to me.

S.

Skarmander, Oct 5, 2005
15. ### SkarmanderGuest

August Karlstrom wrote:
> Skarmander wrote:
>
>> Skarmander wrote:
>>
>>> Keith Thompson wrote:
>>>
>>>> Skarmander <> writes:
>>>> [...]
>>>>
>>>>> Yes: C has no boolean type.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> C99 has _Bool (called "bool" with "#include <stdbool.h>").
>>>>
>>> Pfff. I sort-of semi-deliberately overlooked that, but yes, you're
>>> quite right.
>>>

>>
>> You know, for some reason the C99 bool really annoys me. *Now* they fix
>> things? Too late. Leave it alone. Introducing size_t to provide a new
>> level of abstraction was a good thing. But bool? Not worth the bother,
>> with the backwards compatibility tricks they have to pull.
>>
>> It ticks me off because I'd *like* to use "real" booleans, but if that
>> means requiring a C99 compiler, then no thanks, it's not worth it.
>> Classic chicken and egg story.

>
>
> The real virtue of the bool type is that it conveys more information
> compared to an int used as a boolean type. You never need comments as
> "non-zero if... and zero if...". You still need to know though that it
> is really just an int and that zero is interpreted as `false' and
> non-zero as `true'.
>

Two points. First, yes, I understand the virtue of "bool". Had it been
part of C in the first place, I would be its staunchest defender. It
certainly wouldn't have been anything new: Algol 60 set the example. I
guess K&R just didn't think it was worth including as a separate type --
probably a quirk from C's one-type origins.

Second, exactly because "you still need to know though that it is really
just an int and that zero is interpreted as `false' and non-zero as
`true'", it strikes me as terribly after-the-fact. We can't suddenly
forget about C's booleans-that-are-not-booleans rule -- we have to drag
that nonsense around even with a builtin bool type. The benefit gained
from making your intentions clearer is great, but C has never been a
language that promoted clarity of expression, so I'm not overwhelmed.

S.

Skarmander, Oct 5, 2005
16. ### Martin AmbuhlGuest

August Karlstrom wrote:
> Skarmander wrote:

> The real virtue of the bool type is that it conveys more information
> compared to an int used as a boolean type. You never need comments as
> "non-zero if... and zero if...". You still need to know though that it
> is really just an int and that zero is interpreted as `false' and
> non-zero as `true'.

To describe something that contains less information as conveying more
is at best silly. Nor do you need such comments any more or any less
with a bool type. Tell me why (I) is any more or less in need of such

(I)
{
bool equalp();
/* ... */
if (equalp()) { /* ... */ }
/* ... */
if (!equalp()) { /* ... */ }

}

(II)
{
int equalp();
/* ... */
if (equalp()) { /* ... */ }
/* ... */
if (!equalp()) { /* ... */ }

}

Martin Ambuhl, Oct 5, 2005
17. ### Anonymous 7843Guest

In article <4343ddf7\$0\$11067\$4all.nl>,
Skarmander <> wrote:
>
> Rather than just adding "bool", "true" and "false" to the language
> (which would break many programs even if they use the "right"
> definitions), we've got a new type called _Bool, and if you want to have
> it named "bool", you #include <stdbool.h>. Which you'll always do,
> unless of course you have to be compatible with an existing unit that
> defines "bool".

It feels odd to say this, but I think I would have preferred
that bool, true, and false be always defined in C99, and modules
that use definitions incompatible with this could #include <nostdbool.h>
(or maybe a #define or #pragma) to escape from this.

Actually, it would be neat to have a silent compatibility mode where
modules could create and use their own defininitions of true, false and
bool that are roughly compatibile with stdbool without complaint.

Anonymous 7843, Oct 5, 2005
18. ### Keith ThompsonGuest

Skarmander <> writes:
[...]
> That's what I call a backwards compatibility trick. (OK, so maybe it's
> just one.) _Bool will also be the first keyword beginning with an
> underscore.

_Complex and _Imaginary were introduced at the same time.

I agree that syntax is ugly, and it's not nearly as good as it would
have been if it had been in the language in the first place, but IMHO
it's still an improvement.

--
Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Keith Thompson, Oct 5, 2005
19. ### SkarmanderGuest

Keith Thompson wrote:
> Skarmander <> writes:
> [...]
>
>>That's what I call a backwards compatibility trick. (OK, so maybe it's
>>just one.) _Bool will also be the first keyword beginning with an
>>underscore.

>
>
> _Complex and _Imaginary were introduced at the same time.
>

Ah, yes. The direly needed complex types. But I'll leave that alone;
I'm not a numerics type so I don't consider myself qualified to judge
its merits.

> I agree that syntax is ugly, and it's not nearly as good as it would
> have been if it had been in the language in the first place, but IMHO
> it's still an improvement.
>

When C99 is finally widely established, it probably will be.

S.

Skarmander, Oct 5, 2005
20. ### August KarlstromGuest

Martin Ambuhl wrote:
> August Karlstrom wrote:
>
>> Skarmander wrote:

>
>
>> The real virtue of the bool type is that it conveys more information
>> compared to an int used as a boolean type. You never need comments as
>> "non-zero if... and zero if...". You still need to know though that it
>> is really just an int and that zero is interpreted as `false' and
>> non-zero as `true'.

>
>
> To describe something that contains less information as conveying more
> is at best silly. Nor do you need such comments any more or any less
> with a bool type. Tell me why (I) is any more or less in need of such
>
> (I)
> {
> bool equalp();
> /* ... */
> if (equalp()) { /* ... */ }
> /* ... */
> if (!equalp()) { /* ... */ }
>
> }
>
>
> (II)
> {
> int equalp();
> /* ... */
> if (equalp()) { /* ... */ }
> /* ... */
> if (!equalp()) { /* ... */ }
>
> }

I assume the p suffix stands for "predicate", right? This is a kind of
Hungarian notation that is common practice in languages that lacks a
boolean type, e.g. Emacs lisp. With a boolean type there's no need for
obscure naming, we just go:

{
bool equal();
/* ... */
if (equal()) { /* ... */ }
/* ... */
if (!equal()) { /* ... */ }

}

August

August Karlstrom, Oct 5, 2005