This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: preprocessor issues


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]