This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: preprocessor issues
- To: James Beyer <beyerj at sgi dot com>
- Subject: Re: preprocessor issues
- From: Zack Weinberg <zack at bitmover dot com>
- Date: Mon, 23 Aug 1999 15:27:46 -0700
- cc: gcc-bugs at gcc dot gnu dot org
James Beyer wrote:
>
> Why does the preprocessor not handle directives inside of macro calls?
> It appears that gcc has never handled this although it can be incredibly
> useful when building code for several different architectures.
Several different reasons:
(a) code that puts directives in macro calls is intrinsically
unportable; some preprocessors give fatal errors, some silently mangle
your code, some crash, and very few get it right. The C standard
makes it "undefined behavior" - C-standardese for "illegal and the
compiler doesn't have to do anything sensible." A poll of comp.std.c was
about 20 to 0 in favor of its being a hard syntax error.
(b) It is close to impossible to implement the preprocessor so that it
handles directives inside macro calls correctly. #if-#else-#endif is
not so bad, but consider things like
#define foo(arg) some stuff with arg inside
foo(blah blah blah
#undef foo
blah blah blah)
In the absence of general garbage collection you *cannot* implement
this such that it does what you want and doesn't leak memory.
(c) It is always possible to rewrite code that uses these constructs
so that it doesn't. For the example you gave:
#ifdef TARGET1
CVAL_TO_F_INT (const, VAR1, integer_8);
#else
CVAL_TO_F_INT (const, (SIZE*BITS), integer_8);
#endif
or
#ifndef TARGET1
#define VAR1 (SIZE*BITS)
#endif
CVAL_TO_F_INT (const, VAR1, integer_8)
Personally I think either of these is better style than the original,
as well as not having problems.
I know this answer is not terribly satisfying, but them's the
breaks...
[Gerald: can I add this to the FAQ?]
zw