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

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?

[Skarmander]

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.

[Christopher Benson-Manica]

Paminu <ja******@asd.com> 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.

[Keith Thompson]

Paminu <ja******@asd.com> 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) ks***@mib.org <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]

Skarmander <in*****@dontmailme.com> writes:
[...]

Yes: C has no boolean type.

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.

[Christian Bau]

In article <dh**********@news.net.uni-c.dk>, Paminu <ja******@asd.com>
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.

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]

Keith Thompson wrote:

Skarmander <in*****@dontmailme.com> 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]

Skarmander wrote:

Keith Thompson wrote:

Skarmander <in*****@dontmailme.com> 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.

[Keith Thompson]

Christian Bau <ch***********@cbau.freeserve.co.uk> writes:

In article <dh**********@news.net.uni-c.dk>, Paminu <ja******@asd.com>
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.

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.

[James McIninch]

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.

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

--
Remove '.nospam' from e-mail address to reply by e-mail

[August Karlstrom]

Skarmander wrote:

Skarmander wrote:

Keith Thompson wrote:

Skarmander <in*****@dontmailme.com> 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]

Skarmander wrote:

Skarmander wrote:

Keith Thompson wrote:

Skarmander <in*****@dontmailme.com> 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

[Skarmander]

August Karlstrom wrote:

Skarmander wrote:

Skarmander wrote:

Keith Thompson wrote:

Skarmander <in*****@dontmailme.com> 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]

August Karlstrom wrote:

Skarmander wrote:

Skarmander wrote:

Keith Thompson wrote:

Skarmander <in*****@dontmailme.com> 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.

[Martin Ambuhl]

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

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

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

}

[Anonymous 7843]

In article <43***********************@news.xs4all.nl>,
Skarmander <in*****@dontmailme.com> 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.

[Keith Thompson]

Skarmander <in*****@dontmailme.com> 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) ks***@mib.org <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.

[Skarmander]

Keith Thompson wrote:

Skarmander <in*****@dontmailme.com> 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.

[August Karlstrom]

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

[Thad Smith]

August Karlstrom 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'.

Yes, easier documentation is an advantage and I use it with C90
compilers by declaring a typedef for bool or boolean. Then you can
document as you say. Another good strategy is to choose a boolean
variable name that implies the true state:

bool valveOpen; /* valve is currently open */

as opposed to

bool valveState; /* valve position: 1=open, 0=closed */

Thad

[Martin Ambuhl]

August Karlstrom wrote:

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:

Since your answer is completely nonresponsive, I suppose that means you
actually have nothing to say.

[August Karlstrom]

Martin Ambuhl wrote:

August Karlstrom wrote:

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:

Since your answer is completely nonresponsive, I suppose that means you
actually have nothing to say.

A mutual conclusion, I think ;-)