Re: Esoteric definitions of TRUE and FALSE

Discussion in 'C Programming' started by John Bode, Mar 5, 2011.

  1. John Bode

    John Bode Guest

    On Friday, March 4, 2011 8:30:57 AM UTC-6, Noob wrote:
    > Hello,
    >
    > I've come across a library which defines TRUE and FALSE thus.
    >
    > /* BOOL type constant values */
    > #ifndef TRUE
    > #define TRUE (1 == 1)
    > #endif
    > #ifndef FALSE
    > #define FALSE (!TRUE)
    > #endif
    >
    > Do you know why one would do that


    [snip]

    The most charitable explanation is that they are unfamiliar with how booleans work in C.

    The danger in writing macros for TRUE and FALSE is that, on rare occasions,people will manage to misspell 0 or 1 (or the expression that's supposed to evaluate to 0 or 1). I spent an afternoon chasing my tail because someone dropped a header where TRUE==FALSE.

    Not coincidentally, that was the day I stopped using symbolic constants forBoolean values.
     
    John Bode, Mar 5, 2011
    #1
    1. Advertising

  2. John Bode <> writes:
    > On Friday, March 4, 2011 8:30:57 AM UTC-6, Noob wrote:
    >> Hello,
    >>
    >> I've come across a library which defines TRUE and FALSE thus.
    >>
    >> /* BOOL type constant values */
    >> #ifndef TRUE
    >> #define TRUE (1 == 1)
    >> #endif
    >> #ifndef FALSE
    >> #define FALSE (!TRUE)
    >> #endif
    >>
    >> Do you know why one would do that

    >
    > [snip]
    >
    > The most charitable explanation is that they are unfamiliar with
    > how booleans work in C.
    >
    > The danger in writing macros for TRUE and FALSE is that, on rare
    > occasions, people will manage to misspell 0 or 1 (or the expression
    > that's supposed to evaluate to 0 or 1). I spent an afternoon
    > chasing my tail because someone dropped a header where TRUE==FALSE.


    Did any other code break when you fixed the definitions?

    > Not coincidentally, that was the day I stopped using symbolic
    > constants for Boolean values.


    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Mar 5, 2011
    #2
    1. Advertising

  3. On Fri, 04 Mar 2011 20:09:05 -0500, John Bode <> wrote:

    > The danger in writing macros for TRUE and FALSE is that, on rare
    > occasions, people will manage to misspell 0 or 1 (or the expression
    > that's supposed to evaluate to 0 or 1). I spent an afternoon chasing my
    > tail because someone dropped a header where TRUE==FALSE.


    Here's another one: I've just been looking at some code (which I should
    finish grading, instead of wasting my time on Usenet) with the following
    two lines:

    #define TRUE 1;
    #define FALSE 0;


    --
    Morris Keesan --
     
    Morris Keesan, Mar 5, 2011
    #3
  4. John Bode

    Eric Sosman Guest

    On 3/4/2011 9:36 PM, Morris Keesan wrote:
    > On Fri, 04 Mar 2011 20:09:05 -0500, John Bode <> wrote:
    >
    >> The danger in writing macros for TRUE and FALSE is that, on rare
    >> occasions, people will manage to misspell 0 or 1 (or the expression
    >> that's supposed to evaluate to 0 or 1). I spent an afternoon chasing
    >> my tail because someone dropped a header where TRUE==FALSE.

    >
    > Here's another one: I've just been looking at some code (which I should
    > finish grading, instead of wasting my time on Usenet) with the following
    > two lines:
    >
    > #define TRUE 1;
    > #define FALSE 0;


    Hmmm. Some plausible uses would actually compile:

    ...
    flag = FALSE;
    return TRUE;

    A few compilers, though, would complain about "useless statement"
    or "unreachable statement," or maybe even "unreachable useless
    statement!"

    --
    Eric Sosman
    d
     
    Eric Sosman, Mar 5, 2011
    #4
  5. On Fri, 04 Mar 2011 22:13:09 -0500, Eric Sosman
    <> wrote:

    > On 3/4/2011 9:36 PM, Morris Keesan wrote:
    >> On Fri, 04 Mar 2011 20:09:05 -0500, John Bode <>
    >> wrote:
    >>
    >>> The danger in writing macros for TRUE and FALSE is that, on rare
    >>> occasions, people will manage to misspell 0 or 1 (or the expression
    >>> that's supposed to evaluate to 0 or 1). I spent an afternoon chasing
    >>> my tail because someone dropped a header where TRUE==FALSE.

    >>
    >> Here's another one: I've just been looking at some code (which I should
    >> finish grading, instead of wasting my time on Usenet) with the following
    >> two lines:
    >>
    >> #define TRUE 1;
    >> #define FALSE 0;

    >
    > Hmmm. Some plausible uses would actually compile:
    >
    > ...
    > flag = FALSE;
    > return TRUE;
    >
    > A few compilers, though, would complain about "useless statement"
    > or "unreachable statement," or maybe even "unreachable useless
    > statement!"


    ALL of his uses compiled, which is why those defines were still in the
    code when the homework was submitted. Fortunately, or perhaps
    unfortunately, he only ever used the values in assignment and return
    statements, and never in any context like

    if (condition)
    flag = TRUE;
    else

    --
    Morris Keesan --
     
    Morris Keesan, Mar 5, 2011
    #5
  6. On Mar 5, 10:57 am, "Morris Keesan" <> wrote:

    > ALL of his uses compiled, which is why those defines were still in the
    > code when the homework was submitted. Fortunately, or perhaps
    > unfortunately, he only ever used the values in assignment and return
    > statements, and never in any context like
    >
    > if (condition)
    > flag = TRUE;
    > else


    In the absence of a preceding *if*, that example has the virtue
    of producing a compiler error -- clearly a better outcome than
    faulty code that compiles error-free.

    As I've reported before, I've seen similar flaws in glibc source,
    so your student is in "good" company. :)

    James
     
    James Dow Allen, Mar 5, 2011
    #6
  7. On Mar 5, 4:35 pm, James Dow Allen <> wrote:
    > On Mar 5, 10:57 am, "Morris Keesan" <> wrote:
    >
    > > ALL of his uses compiled, which is why those defines were still in the
    > > code when the homework was submitted.  Fortunately, or perhaps
    > > unfortunately, he only ever used the values in assignment and return
    > > statements, and never in any context like

    >
    > >    if (condition)
    > >        flag = TRUE;
    > >    else

    >
    > In the absence of a preceding *if*, that example has the virtue
    > of producing a compiler error -- clearly a better outcome than
    > faulty code that compiles error-free.


    On reread, what I wrote makes no sense! :-(

    Puzzle 1: Is there any error-free program where
    replacing ";" with ";;" yields an *error-free*
    program with different semantic meaning?

    Puzzle 2: Given a macro definition like
    #define TRUE 1;
    what is the *least-contrived* error-free program where
    the extra ";" yields an *error-free* program with
    different semantic meaning?

    James
     
    James Dow Allen, Mar 5, 2011
    #7
  8. James Dow Allen <> writes:
    <snip>
    > Puzzle 1: Is there any error-free program where
    > replacing ";" with ";;" yields an *error-free*
    > program with different semantic meaning?


    Yes[1].

    > Puzzle 2: Given a macro definition like
    > #define TRUE 1;
    > what is the *least-contrived* error-free program where
    > the extra ";" yields an *error-free* program with
    > different semantic meaning?


    I can see a lot of noise being generated over the measure used for
    "contrived" but I can't think of an any entirely normal usage of the
    macro that would cause such trouble. However, operators that are both
    unary and binary are problematic after semicolons. For example,

    int x = TRUE - y;

    but Boolean operands are hardly normal for + and -.

    [1] Spoiler...

    I was going to post an example rot13-ed but the key elements are not
    hidden by rot13 in this case:

    #include <stdio.h>
    #define s(a) #a
    int main(void) { puts(s(;)); }

    --
    Ben.
     
    Ben Bacarisse, Mar 5, 2011
    #8
    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:
    677
    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,050
    Grant Edwards
    Dec 16, 2005
  3. André
    Replies:
    3
    Views:
    1,625
  4. bdb112
    Replies:
    45
    Views:
    1,379
    jazbees
    Apr 29, 2009
  5. Noob

    Esoteric definitions of TRUE and FALSE

    Noob, Mar 4, 2011, in forum: C Programming
    Replies:
    54
    Views:
    1,237
    Tim Rentsch
    Mar 17, 2011
Loading...

Share This Page