Which numbers evaluate to true and false?

[Paminu]

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]

Nearly. 0 evaluates to false and any other number to true (I am not completely
sure about floating point).

Cheers,
Chris

 

[Skarmander]

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.

 

[Christopher Benson-Manica]

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.

 

[Keith Thompson]

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]

Yes: C has no boolean type.

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

 

[Christian Bau]

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.

You can download a copy of the Final Draft of the C99 Standard for free
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
purposes. You can download the C Standard from

http://www.ansi.org/

as far as I know for US$18.

To answer your original question,

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

 

[Skarmander]

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]

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.

 

[Keith Thompson]

You can download a copy of the Final Draft of the C99 Standard for free
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
purposes. You can download the C Standard from

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.

 

[James McIninch]

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.

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?

No secret. Any C language reference will tell you:

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

 

[August Karlstrom]

[...]

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]

[...]

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

 

[Skarmander]

Keith Thompson wrote:

[...]

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]

Keith Thompson wrote:

[...]

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.

 

[Martin Ambuhl]

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
comments than (II).

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

}


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

}

 

[Anonymous 7843]

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.

 

[Keith Thompson]

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.

 

[Skarmander]

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

 

[August Karlstrom]

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
comments than (II).

(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