Re: -fpreprocessed, directives, #line and other fun

["Zack Weinberg" <zackw at Stanford dot EDU>]

On Thu, Nov 30, 2000 at 10:43:06PM +0000, Neil Booth wrote:
> Zack Weinberg wrote:-
> 
> > We really shouldn't allow any directives with -fpreprocessed.  The
> > reason we accept #define now is so that if you write -g3 -save-temps,
> > the compiler's callback for the #define will still get run.
> 
> Are you saying we should accept #define (and by implication #undef),
> and no others?  We don't generate the callbacks for command line
> options...

What we really ought to do is run the callback for #define and #undef,
but not bother recording the macro expansion.

> If we want to bother to get this right too (I don't mind either way),
> we could check for lack of a space before the "define".  It's a kludge
> but it would work provided we ensure cppmain.c doesn't insert one,
> which it doesn't at present.

What about this?

#define P(a,b) _P(a,b)
#define _P(a,b) a##b
#define HASH #
P(HASH,define) foo bar

You'll get "#define foo bar" with no spaces (and a warning, but never
mind).  You can fake up # 123 lines with HASH, too...

Basically, we don't have a safe way to insert out-of-band information
into an .i file.  But here's an idea: If we're ever about to emit an #
in column 1 as the result of input text, except within a multiline
string constant, insert a space before it.  So the above would produce

 #define foo bar

and if you tried to synthesize a #123 line you'd get 

 # 123 "foo.h" ...

Then, when -fpreprocessed, ignore directives unless their # is in
column 1, as if we were -traditional.  Then we'll be sure they only
result from callback handlers inserting out-of-band data in the output
stream.

zw