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

A

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)
 
S

S.Tobias

Alex Vinokur said:
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?
 
N

Neo

S.Tobias said:
Alex Vinokur said:
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
 
C

Chris Croughton

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

S.Tobias

Neo said:

[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, [...]

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.
 
K

Keith Thompson

Neo said:
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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top