Which numbers evaluate to true and false?

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

  1. Paminu

    Paminu Guest

    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?
    Paminu, Oct 4, 2005
    #1
    1. Advertising

  2. 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?
    Christoph Schmidt, Oct 4, 2005
    #2
    1. Advertising

  3. Paminu

    Skarmander Guest

    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
    #3
  4. 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
    #4
  5. 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
    #5
  6. 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
    #6
  7. 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.


    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".
    Christian Bau, Oct 4, 2005
    #7
  8. Paminu

    Skarmander Guest

    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
    #8
  9. Paminu

    Skarmander Guest

    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
    #9
  10. 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.

    >
    > 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) <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
    #10
  11. 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
    James McIninch, Oct 4, 2005
    #11
  12. 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
    #12
  13. 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
    #13
  14. Paminu

    Skarmander Guest

    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
    #14
  15. Paminu

    Skarmander Guest

    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
    #15
  16. 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()) { /* ... */ }

    }
    Martin Ambuhl, Oct 5, 2005
    #16
  17. 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
    #17
  18. 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
    #18
  19. Paminu

    Skarmander Guest

    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
    #19
  20. 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
    August Karlstrom, Oct 5, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Siemel Naran

    Does true ^ true return false?

    Siemel Naran, Jun 17, 2004, in forum: C++
    Replies:
    19
    Views:
    664
    Chris Theis
    Jun 18, 2004
  2. Pierre Quentel

    "0 in [True,False]" returns True

    Pierre Quentel, Dec 12, 2005, in forum: Python
    Replies:
    59
    Views:
    1,030
    Grant Edwards
    Dec 16, 2005
  3. André
    Replies:
    3
    Views:
    1,586
  4. bdb112
    Replies:
    45
    Views:
    1,341
    jazbees
    Apr 29, 2009
  5. Shea Martin

    false or true == true .... WTF?

    Shea Martin, Apr 5, 2007, in forum: Ruby
    Replies:
    4
    Views:
    105
    Bertram Scharpf
    Apr 5, 2007
Loading...

Share This Page