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

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

On Thu, Nov 30, 2000 at 07:06:50PM +0000, Neil Booth wrote:

> Questions:-
> 
> o Should we allow the #line form in -fpreprocessed?

Probably not.

> o More generally, why should we allow *any* directive other than
>   #number with -fpreprocessed?  Things like -dD and -dI are just for
>   debugging, right? It seems inconsistent to allow #define and expand
>   macros therefrom, if we ignore -D.

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.

This is difficult to get 100% right.  If I write

#define HASH #

HASH define foo bar

foo

with -g3 -save-temps, the temp file will contain

#define HASH #

# define foo bar

foo

-- and the compiler's callback ought to be run for #define HASH, but
the "# define foo bar" line should be passed through as ordinary
text.

However, I don't think it's possible to construct a well-formed
program that will notice.


>      gcc -c -include ~/test.h ~/test.c
> 
> Currently we get
> 
> # 1 "/home/neil/test.c"
> # 1 "/home/neil/test.h" 1
> 
>   [test.h stuff]
> 
> # 2 "/home/neil/test.c" 2     [This is a bug - the line number is wrong]
> 
>   [test.c stuff]

I vote for this form, with the line numbers corrected.  IMHO the
effect of -include file should be as if '#include "file"' appeared on
the first line of the primary source file.

zw