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

[Alex Vinokur]

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

[S.Tobias]

Alex Vinokur <al****@big-foot.com> 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 si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Neo]

"S.Tobias" <si***@FamOuS.BedBuG.pAlS.INVALID> wrote in message
news:30*************@uni-berlin.de...

Alex Vinokur <al****@big-foot.com> 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 si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Chris Croughton]

On 25 Nov 2004 10:58:49 GMT, S.Tobias
<si***@FamOuS.BedBuG.pAlS.INVALID> 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

[S.Tobias]

Neo <ti***************@yahoo.com> wrote:

"S.Tobias" <si***@FamOuS.BedBuG.pAlS.INVALID> wrote in message
news:30*************@uni-berlin.de...
[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 si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Keith Thompson]

"Neo" <ti***************@yahoo.com> 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) 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.