assert(x) and '#define ASSERT(x) assert(x)'

Discussion in 'C Programming' started by Alex Vinokur, Nov 25, 2004.

  1. Alex Vinokur

    Alex Vinokur Guest

    Here are two programs.

    --- foo1.c ---
    #include <assert.h>
    #define FOO 10
    int main()
    {
    assert (15 < FOO);
    return 0;
    }
    -------------

    --- foo2.c ---
    #include <assert.h>
    #define FOO 10
    #define ASSERT(x) assert(x)
    int main()
    {
    ASSERT (17 < FOO);
    return 0;
    }
    -------------

    // gcc 3.3.3

    $ gcc -W -Wall foo1.c -o a1
    // No errors/warnings

    $ gcc -W -Wall foo2.c -o a2
    // No errors/warnings

    $ ./a1
    assertion "15 < FOO" failed: file "foo1.c", line 5
    Aborted (core dumped)

    $ ./a2
    assertion "17 < 10" failed: file "foo2.c", line 6
    Aborted (core dumped)

    $ gcc -dM -E foo1.c | grep ASSERT
    // No output

    $ gcc -dM -E foo2.c | grep ASSERT
    #define ASSERT(x) assert(x)


    -------------------------------------
    Why does a1 print "15 < FOO", but not "15 < FOO"?
    Why does a2 print "17 < 10", but not "17 < FOO"?


    --
    Alex Vinokur
    email: alex DOT vinokur AT gmail DOT com
    http://mathforum.org/library/view/10978.html
    http://sourceforge.net/users/alexvn
     
    Alex Vinokur, Nov 25, 2004
    #1
    1. Advertising

  2. Alex Vinokur

    S.Tobias Guest

    Alex Vinokur <> wrote:
    > Here are two programs.


    > --- foo1.c ---
    > #include <assert.h>
    > #define FOO 10
    > int main()
    > {
    > assert (15 < FOO);
    > return 0;
    > }
    > -------------


    > --- foo2.c ---
    > #include <assert.h>
    > #define FOO 10
    > #define ASSERT(x) assert(x)
    > int main()
    > {
    > ASSERT (17 < FOO);
    > return 0;
    > }
    > -------------

    [snip]

    [reordered]
    > Why does a2 print "17 < 10", but not "17 < FOO"?


    Macro call
    ASSERT (17 < FOO)
    is expanded at first to:
    assert ( 17 < 10 )
    and then the above is expanded further, so its obvious
    you can't expect anything else.


    > Why does a1 print "15 < FOO", but not "15 < FOO"?

    ITYM: "15 < 10"

    Now I'm stuck here, perhaps someone else confirm this:

    7.2.1.1 The assert macro
    [...] the assert macro writes
    information about the particular call that failed (including
    the text of the argument, [...]

    IMO the argument to the *macro* is: `17 < FOO', and it's stringified
    version is: "15 < FOO". I think in this case assert() *must not*
    expand it's argument for print-out.

    But in my GNU C libraries (in two versions; this is a library, not a
    compiler version issue) in /usr/include/assert.h in the definition of
    assert() the argument is stringified _indirectly_ via another function-like
    macro (__STRING()), hence it is expanded before strigification. In both
    cases it printed "15 < 10" or "17 < 10" on my system, which I consider
    incorrect. Could somebody valuate my supposition?

    --
    Stan Tobias
    mailx `echo LID | sed s/[[:upper:]]//g`
     
    S.Tobias, Nov 25, 2004
    #2
    1. Advertising

  3. Alex Vinokur

    Neo Guest

    "S.Tobias" <> wrote in message
    news:...
    > Alex Vinokur <> wrote:
    >> Here are two programs.

    >
    >> --- foo1.c ---
    >> #include <assert.h>
    >> #define FOO 10
    >> int main()
    >> {
    >> assert (15 < FOO);
    >> return 0;
    >> }
    >> -------------

    >
    >> --- foo2.c ---
    >> #include <assert.h>
    >> #define FOO 10
    >> #define ASSERT(x) assert(x)
    >> int main()
    >> {
    >> ASSERT (17 < FOO);
    >> return 0;
    >> }
    >> -------------

    > [snip]
    >
    > [reordered]
    >> Why does a2 print "17 < 10", but not "17 < FOO"?

    >
    > Macro call
    > ASSERT (17 < FOO)
    > is expanded at first to:
    > assert ( 17 < 10 )
    > and then the above is expanded further, so its obvious
    > you can't expect anything else.
    >
    >
    >> Why does a1 print "15 < FOO", but not "15 < FOO"?

    > ITYM: "15 < 10"
    >
    > Now I'm stuck here, perhaps someone else confirm this:
    >
    > 7.2.1.1 The assert macro
    > [...] the assert macro writes
    > information about the particular call that failed (including
    > the text of the argument, [...]
    >


    Stan, could U plz. tell me from where do U quote these specification
    and from where can I get the same?
    -Neo

    > IMO the argument to the *macro* is: `17 < FOO', and it's stringified
    > version is: "15 < FOO". I think in this case assert() *must not*
    > expand it's argument for print-out.
    >
    > But in my GNU C libraries (in two versions; this is a library, not a
    > compiler version issue) in /usr/include/assert.h in the definition of
    > assert() the argument is stringified _indirectly_ via another
    > function-like
    > macro (__STRING()), hence it is expanded before strigification. In both
    > cases it printed "15 < 10" or "17 < 10" on my system, which I consider
    > incorrect. Could somebody valuate my supposition?
    >
    > --
    > Stan Tobias
    > mailx `echo LID | sed s/[[:upper:]]//g`
     
    Neo, Nov 25, 2004
    #3
  4. On 25 Nov 2004 10:58:49 GMT, S.Tobias
    <> wrote:

    > Now I'm stuck here, perhaps someone else confirm this:
    >
    > 7.2.1.1 The assert macro
    > [...] the assert macro writes
    > information about the particular call that failed (including
    > the text of the argument, [...]
    >
    > IMO the argument to the *macro* is: `17 < FOO', and it's stringified
    > version is: "15 < FOO". I think in this case assert() *must not*
    > expand it's argument for print-out.
    >
    > But in my GNU C libraries (in two versions; this is a library, not a
    > compiler version issue) in /usr/include/assert.h in the definition of
    > assert() the argument is stringified _indirectly_ via another function-like
    > macro (__STRING()), hence it is expanded before strigification. In both
    > cases it printed "15 < 10" or "17 < 10" on my system, which I consider
    > incorrect. Could somebody valuate my supposition?


    Borland C on Windows prints "15 < FOO" for the first, as does GCC 3.3.3
    under Cygwin (no extra 'stringize' macros in assert.h for either).
    Perhaps this is something which is specific to Linux headers? My Linux
    versions (2.2.x kernels, Debian 'woody' release) have the incorrect
    definition. FreeBSD 5.1 has a correct one. I don't have access at the
    moment to a Solaris system...

    Chris C
     
    Chris Croughton, Nov 25, 2004
    #4
  5. Alex Vinokur

    S.Tobias Guest

    Neo <> wrote:
    > "S.Tobias" <> wrote in message
    > news:...


    [snip 40 lines of *completely unrelated* quotes]

    > > 7.2.1.1 The assert macro
    > > [...] the assert macro writes
    > > information about the particular call that failed (including
    > > the text of the argument, [...]
    > >


    > Stan,


    Since you called me by name, I'll try to answer you:

    > could U plz.


    I have no idea whether U could plz. I swear, I have never
    seen U plzing anywhere. I guess I couldn't do it either.

    > tell me from where do U quote these specification


    I'm sure U didn't quote them, because actually it was I.
    Does it really look as if U did it?

    > and from where can I get the same?


    I will tell you, and I think many others here would too, when
    you learn to write nice English; I'm sure you could. :)

    [snip another block of *noise*]

    Please, try again.

    --
    Stan Tobias
    mailx `echo LID | sed s/[[:upper:]]//g`
     
    S.Tobias, Nov 25, 2004
    #5
  6. "Neo" <> writes:
    [...]
    > Stan, could U plz. tell me from where do U quote these specification
    > and from where can I get the same?
    > -Neo


    Neo, you need to learn some of the conventions we use when we post
    here. It's "you", not "U", and "please", not "plz". Abbreviations
    like that are ok when you're entering messages on a phone keypad (or
    whatever), but they're frowned on here. We'll make allowances for
    grammar and spelling if English is not your native language (or even
    if it is), but thinks like "could U plz." just make your articles more
    difficult to read. You only need to write it once; it's likely to be
    read hundreds of times. Take the time to make our job a little
    easier.

    Also, it's rarely necessary to quote the entire article to which
    you're responding. Delete anything not relevant to your response, as
    I've done here.

    The specification Stan was referring to is the C99 standard, ISO/IEC
    9899:1999 (E). It's not freely available, but you can buy a PDF copy
    from ANSI for $18 (but watch out for the licensing terms). Other
    national bodies can probably also sell you a copy.

    The latest public draft is N869; a Google search should easily turn up
    a copy of it. It's very close to the final standard.

    --
    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, Nov 25, 2004
    #6
    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. Pete Becker
    Replies:
    5
    Views:
    2,196
  2. Robert Brewer
    Replies:
    1
    Views:
    512
    bsmith
    Nov 7, 2004
  3. Thomas Guettler

    assert 0, "foo" vs. assert(0, "foo")

    Thomas Guettler, Feb 23, 2005, in forum: Python
    Replies:
    3
    Views:
    2,556
    Carl Banks
    Feb 23, 2005
  4. Alex Vinokur
    Replies:
    2
    Views:
    569
    Eric Sosman
    Jan 7, 2009
  5. ImpalerCore

    To assert or not to assert...

    ImpalerCore, Apr 27, 2010, in forum: C Programming
    Replies:
    79
    Views:
    1,730
    Richard Bos
    May 17, 2010
Loading...

Share This Page