rationale for #define true 1 in stdbool.h

Discussion in 'C Programming' started by Ben Hinkle, Jan 10, 2006.

  1. Ben Hinkle

    Ben Hinkle Guest

    I'm curious, what was the rationale for making a builtin type _Bool but then
    having
    #define true 1
    #define false 0
    in stdbool.h? That seems very odd that true and false don't have type _Bool.
    In particular I'm poking around with some language extensions to C and one
    of the most obvious extensions is overloading. Since "true" doesn't have
    type _Bool it makes overloading behavior with _Bool very odd. You'd think
    that at least it could be
    #define true ((bool)1)

    I notice in the C99 spec it says the true and false defines "are suitable
    for use in #if preprocessor directives". Was it anticipated that true and
    false would be used primarily for #if directives? One would imagine that a
    more important property would be something like sizeof(bool) ==
    sizeof(true).

    thanks,
    -Ben
     
    Ben Hinkle, Jan 10, 2006
    #1
    1. Advertising

  2. Ben Hinkle

    Eric Sosman Guest

    Ben Hinkle wrote On 01/10/06 16:18,:
    > I'm curious, what was the rationale for making a builtin type _Bool but then
    > having
    > #define true 1
    > #define false 0
    > in stdbool.h? That seems very odd that true and false don't have type _Bool.
    > In particular I'm poking around with some language extensions to C and one
    > of the most obvious extensions is overloading. Since "true" doesn't have
    > type _Bool it makes overloading behavior with _Bool very odd. You'd think
    > that at least it could be
    > #define true ((bool)1)
    >
    > I notice in the C99 spec it says the true and false defines "are suitable
    > for use in #if preprocessor directives". Was it anticipated that true and
    > false would be used primarily for #if directives? One would imagine that a
    > more important property would be something like sizeof(bool) ==
    > sizeof(true).


    "Suitable for use in #if" is one reason (bool)1 wouldn't
    work. Types do not yet exist when the preprocessor operates,
    so casts can't be evaluated. (In fact, #if true would turn
    into #if (bool)1 and then #if (0)1, eliciting a diagnostic.)

    As for the sizeof complaint, although opinions obviously
    vary it doesn't strike me as an "important" property. IMHO
    it is usually -- not always, but usually -- a poor idea to
    write sizeof(type) when sizeof *ptr is practical. Besides,
    we've already got sizeof 'x' > sizeof(char) on most systems,
    and the only people it seems to bother are defectors to the
    Dark Side With The Plus Signs.

    Personally, I still don't understand the motivation for
    adding _Bool to the language. The Rationale draws attention
    to some properties of _Bool, but sheds no light on why those
    properties were so desirable as to prompt the addition of a
    whole new type -- especially since everything that can be
    done with _Bool seems eminently do-able without it. Perhaps
    the C9X committee suffered from Pascal envy?

    --
     
    Eric Sosman, Jan 10, 2006
    #2
    1. Advertising

  3. Ben Hinkle

    Old Wolf Guest

    Eric Sosman wrote:

    > Personally, I still don't understand the motivation for
    > adding _Bool to the language.


    For me, it's desirable because assigning any non-zero value
    to it causes it to have a non-zero value. This is not true for
    any builtin type except for unsigned long long, which would
    be a waste of memory if it were used as a boolean type.

    I have accidentally written code like this:

    bool b = (flags & FLAG_FOO);

    where FLAG_FOO is something like 0x100. It took a
    long debugging session to track down the problem; even
    when I'd isolated the problem to this one block of code,
    I still couldn't for the life of me figure out what was going on,
    until I looked up the definition of 'bool'. (It turned out to
    be a typedef for unsigned char).
     
    Old Wolf, Jan 11, 2006
    #3
  4. "Ben Hinkle" <> writes:
    > I'm curious, what was the rationale for making a builtin type _Bool but then
    > having
    > #define true 1
    > #define false 0
    > in stdbool.h? That seems very odd that true and false don't have type _Bool.
    > In particular I'm poking around with some language extensions to C and one
    > of the most obvious extensions is overloading. Since "true" doesn't have
    > type _Bool it makes overloading behavior with _Bool very odd. You'd think
    > that at least it could be
    > #define true ((bool)1)
    >
    > I notice in the C99 spec it says the true and false defines "are suitable
    > for use in #if preprocessor directives". Was it anticipated that true and
    > false would be used primarily for #if directives? One would imagine that a
    > more important property would be something like sizeof(bool) ==
    > sizeof(true).


    Character constants don't have type char either; they're of type int
    (sizeof('a')==sizeof(int)).

    Making true and false be of type _Bool wouldn't be very useful, since
    they'd be promoted to int in most contexts anyway.

    If the language had been changed so that all conditions must be of
    type _Bool, rather than of any scalar type, making false and true be
    of type _Bool might have made more sense -- but that kind of change
    would break existing code.

    --
    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, Jan 11, 2006
    #4
  5. Ben Hinkle

    Ben Hinkle Guest

    "Eric Sosman" <> wrote in message
    news:...
    >
    >
    > Ben Hinkle wrote On 01/10/06 16:18,:
    >> I'm curious, what was the rationale for making a builtin type _Bool but
    >> then
    >> having
    >> #define true 1
    >> #define false 0
    >> in stdbool.h? That seems very odd that true and false don't have type
    >> _Bool.
    >> In particular I'm poking around with some language extensions to C and
    >> one
    >> of the most obvious extensions is overloading. Since "true" doesn't have
    >> type _Bool it makes overloading behavior with _Bool very odd. You'd think
    >> that at least it could be
    >> #define true ((bool)1)
    >>
    >> I notice in the C99 spec it says the true and false defines "are suitable
    >> for use in #if preprocessor directives". Was it anticipated that true and
    >> false would be used primarily for #if directives? One would imagine that
    >> a
    >> more important property would be something like sizeof(bool) ==
    >> sizeof(true).

    >
    > "Suitable for use in #if" is one reason (bool)1 wouldn't
    > work. Types do not yet exist when the preprocessor operates,
    > so casts can't be evaluated. (In fact, #if true would turn
    > into #if (bool)1 and then #if (0)1, eliciting a diagnostic.)


    Right. I wouldn't consider using true and false in #if's important.

    > As for the sizeof complaint, although opinions obviously
    > vary it doesn't strike me as an "important" property. IMHO
    > it is usually -- not always, but usually -- a poor idea to
    > write sizeof(type) when sizeof *ptr is practical. Besides,
    > we've already got sizeof 'x' > sizeof(char) on most systems,
    > and the only people it seems to bother are defectors to the
    > Dark Side With The Plus Signs.


    I'm with Them, then. Justifying one "mistake" (#define true 1) with another
    (type of 'a' isn't char) doesn't make me feel warm and fuzzy. I assume there
    are good reasons for things, though.

    > Personally, I still don't understand the motivation for
    > adding _Bool to the language. The Rationale draws attention
    > to some properties of _Bool, but sheds no light on why those
    > properties were so desirable as to prompt the addition of a
    > whole new type -- especially since everything that can be
    > done with _Bool seems eminently do-able without it. Perhaps
    > the C9X committee suffered from Pascal envy?


    Not enough Pascal envy, perhaps ;-)

    >
    > --
    >
    >
     
    Ben Hinkle, Jan 11, 2006
    #5
  6. Eric Sosman wrote:
    >
    > Personally, I still don't understand the motivation for
    > adding _Bool to the language. The Rationale draws attention
    > to some properties of _Bool, but sheds no light on why those
    > properties were so desirable as to prompt the addition of a
    > whole new type -- especially since everything that can be
    > done with _Bool seems eminently do-able without it. Perhaps
    > the C9X committee suffered from Pascal envy?


    Or perhaps the C9X committee could see the plethora of
    programs that already have varing (and subtly incompatible)
    kludges for the same thing that was missing from C originally,
    namely, a basic boolean type.

    --
    Peter
     
    Peter Nilsson, Jan 11, 2006
    #6
  7. Ben Hinkle

    Eric Sosman Guest

    Old Wolf wrote:

    > Eric Sosman wrote:
    >
    >
    >> Personally, I still don't understand the motivation for
    >>adding _Bool to the language.

    >
    >
    > For me, it's desirable because assigning any non-zero value
    > to it causes it to have a non-zero value. This is not true for
    > any builtin type except for unsigned long long, which would
    > be a waste of memory if it were used as a boolean type.
    >
    > I have accidentally written code like this:
    >
    > bool b = (flags & FLAG_FOO);
    >
    > where FLAG_FOO is something like 0x100. It took a
    > long debugging session to track down the problem; even
    > when I'd isolated the problem to this one block of code,
    > I still couldn't for the life of me figure out what was going on,
    > until I looked up the definition of 'bool'. (It turned out to
    > be a typedef for unsigned char).


    Accidents will happen (and have to me, most certainly).
    This particular accident isn't one that has beset my path
    and laid a trap for my unwary feet; in the "isolate the
    bit" context I tend to think of (and write) the result in
    the same type as the original flags, not as a truth value
    saying "was it set, or was it not?"

    Still, if one wants the WISOWIN semantics, one can
    always resort to the double negative:

    bool b = !!(flags & FLAG_FOO);

    or the (possibly clearer)

    bool b = (flags & FLAG_FOO) != 0;

    Thirty-five-plus years of C somehow scraped by without
    anything more, and I still don't see what _Bool brings to
    the party. Well, maybe I'm just a party pooper.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jan 11, 2006
    #7
  8. Ben Hinkle

    Chris Torek Guest

    >Eric Sosman wrote:
    >> Personally, I still don't understand the motivation for
    >> adding _Bool to the language. ...


    In article <>
    Peter Nilsson <> wrote:
    >Or perhaps the C9X committee could see the plethora of
    >programs that already have varing (and subtly incompatible)
    >kludges for the same thing that was missing from C originally,
    >namely, a basic boolean type.


    In other words, there was a demand, so they filled it.

    Of course, there is also a lot of demand for methamphetamine. :)

    (Or as Rob Pike said of the X Window System: "Sometimes when you
    fill a vacuum, it still sucks.")
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Jan 11, 2006
    #8
  9. Ben Hinkle

    Chuck F. Guest

    Eric Sosman wrote:
    >

    .... snip ...
    >
    > Thirty-five-plus years of C somehow scraped by without anything
    > more, and I still don't see what _Bool brings to the party.
    > Well, maybe I'm just a party pooper.


    You can always avoid it by simply failing to #include <stdbool.h>.
    Then the only evidence remaining is an identifier in the
    implementors namespace. But for people who do want to define true,
    false, and bool, everything is standardized.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    More details at: <http://cfaj.freeshell.org/google/>
     
    Chuck F., Jan 11, 2006
    #9
  10. Ben Hinkle

    Alex Fraser Guest

    "Keith Thompson" <> wrote in message
    news:...
    [snip]
    > Making true and false be of type _Bool wouldn't be very useful, since
    > they'd be promoted to int in most contexts anyway.


    Which leads to the obvious question: why are "small" types promoted to int?

    > If the language had been changed so that all conditions must be of
    > type _Bool, rather than of any scalar type, making false and true be
    > of type _Bool might have made more sense -- but that kind of change
    > would break existing code.


    I guess you would also want to change the type of the result of the equality
    and relational operators.

    Alex
     
    Alex Fraser, Jan 11, 2006
    #10
  11. "Alex Fraser" <> writes:
    > "Keith Thompson" <> wrote in message
    > news:...
    > [snip]
    >> Making true and false be of type _Bool wouldn't be very useful, since
    >> they'd be promoted to int in most contexts anyway.

    >
    > Which leads to the obvious question: why are "small" types promoted to int?


    Historical reasons and code efficiency, I think.

    For many CPUs, arithmetic operations single-word operands are more
    efficient than operations on smaller operands. Given:

    short x, y, z;
    ... x * y + z ...

    promoting each operand from short (perhaps 16 bits) to int (perhaps 32
    bits) is likely to result in faster code than performin the operations
    on the short operands (which might not even be directly supported by
    the hardware).

    Making the semantics consistent across different CPUs is probably
    better than doing it in the most efficient way for each system,
    causing some apparently straightforward operations to be
    implementation-defined.

    --
    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, Jan 11, 2006
    #11
  12. Ben Hinkle

    Ben Hinkle Guest

    "Chuck F. " <> wrote in message
    news:...
    > Eric Sosman wrote:
    >>

    > ... snip ...
    >>
    >> Thirty-five-plus years of C somehow scraped by without anything
    >> more, and I still don't see what _Bool brings to the party.
    >> Well, maybe I'm just a party pooper.

    >
    > You can always avoid it by simply failing to #include <stdbool.h>. Then
    > the only evidence remaining is an identifier in the implementors
    > namespace. But for people who do want to define true, false, and bool,
    > everything is standardized.


    But if the intention is that stdbool be used for standard boolean coding
    then it will appear in headers and once you include someone's header that
    uses it then you are using it, too. So if the intention of stdbool is that
    it is included in, say, 90% of headers that involve function taking a
    boolean parameter then as an individual there's not much one can do to avoid
    it. However if the intention is that it gets used by a few individuals (more
    particuarly, not in library headers) then how it behaves isn't a big deal.

    -Ben
     
    Ben Hinkle, Jan 11, 2006
    #12
  13. Ben Hinkle

    Guest

    Eric Sosman <> wrote:
    >
    > Personally, I still don't understand the motivation for
    > adding _Bool to the language.


    The main reason was that a huge number of third-party packages define
    some sort of boolean type, but while they usually don't agree on the
    definition, they frequently agree on the name, leading to problems for
    anyone trying to use them together. Having a standard boolean type was
    viewed as the obvious solution to that problem.

    -Larry Jones

    They say winning isn't everything, and I've decided
    to take their word for it. -- Calvin
     
    , Jan 11, 2006
    #13
  14. Ben Hinkle

    Guest

    Old Wolf <> wrote:
    >
    > For me, it's desirable because assigning any non-zero value
    > to it causes it to have a non-zero value. This is not true for
    > any builtin type except for unsigned long long [...]


    unsigned long long l = 0.1;

    -Larry Jones

    I'll be a hulking, surly teen-ager before you know it!! -- Calvin
     
    , Jan 11, 2006
    #14
  15. Ben Hinkle

    Jordan Abel Guest

    On 2006-01-11, Ben Hinkle <> wrote:
    >
    > "Chuck F. " <> wrote in message
    > news:...
    >> Eric Sosman wrote:
    >>>

    >> ... snip ...
    >>>
    >>> Thirty-five-plus years of C somehow scraped by without anything
    >>> more, and I still don't see what _Bool brings to the party.
    >>> Well, maybe I'm just a party pooper.

    >>
    >> You can always avoid it by simply failing to #include <stdbool.h>. Then
    >> the only evidence remaining is an identifier in the implementors
    >> namespace. But for people who do want to define true, false, and bool,
    >> everything is standardized.

    >
    > But if the intention is that stdbool be used for standard boolean coding
    > then it will appear in headers and once you include someone's header that
    > uses it then you are using it, too. So if the intention of stdbool is that
    > it is included in, say, 90% of headers that involve function taking a
    > boolean parameter then as an individual there's not much one can do to avoid
    > it. However if the intention is that it gets used by a few individuals (more
    > particuarly, not in library headers) then how it behaves isn't a big deal.
    >
    > -Ben


    function declarations in headers could just use _Bool instead.
     
    Jordan Abel, Jan 11, 2006
    #15
  16. Ben Hinkle

    Old Wolf Guest

    Eric Sosman wrote:
    > Old Wolf wrote:
    >> Eric Sosman wrote:
    >>> Personally, I still don't understand the motivation for
    >>>adding _Bool to the language.

    >>
    >> I have accidentally written code like this:
    >>
    >> bool b = (flags & FLAG_FOO);
    >>
    >> where FLAG_FOO is something like 0x100. I

    >
    > Accidents will happen (and have to me, most certainly).
    > This particular accident isn't one that has beset my path
    > and laid a trap for my unwary feet;


    In fact my situation was a bit more disguised:

    bool test_foo(FLAGS flags)
    {
    return flags & FLAG_FOO;
    }

    > bool b = !!(flags & FLAG_FOO);


    Yes, once I had been alerted to the danger, I went through all of
    my source-code looking for such things, and did that to them.
     
    Old Wolf, Jan 12, 2006
    #16
    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:
    669
    Chris Theis
    Jun 18, 2004
  2. Chip
    Replies:
    6
    Views:
    2,637
    E. Robert Tisdale
    Jan 8, 2005
  3. Tristan Miller

    stdbool.h and backward compatibility

    Tristan Miller, Dec 11, 2003, in forum: C Programming
    Replies:
    1
    Views:
    1,052
    Goran Larsson
    Dec 13, 2003
  4. bdb112
    Replies:
    45
    Views:
    1,348
    jazbees
    Apr 29, 2009
  5. Jorgen Grahn

    stdbool.h

    Jorgen Grahn, Mar 1, 2014, in forum: C Programming
    Replies:
    110
    Views:
    759
    David Brown
    Jun 12, 2014
Loading...

Share This Page