Re: "#" directive affects compilation ?

[Ian Lance Taylor <iant at google dot com>]

"Michael Gong" <mwgong@cs.utoronto.ca> writes:

> It might be a basic question. I always think that the "#" directive in
> the preprocessed file won't affect compilation, but following example
> shows that I am wrong. Can anyone give a quick explanation ?
> 
> /* t1.c */
> # 1 "foo.c"
> # 1 "<built-in>"
> # 1 "<command line>"
> # 1 "foo.c"
> # 1 "/usr/include/stdlib.h" 1 3
> # 25 "/usr/include/stdlib.h" 3
> # 1 "/usr/include/features.h" 1 3
> # 295 "/usr/include/features.h" 3
> # 1 "/usr/include/sys/cdefs.h" 1 3
> # 296 "/usr/include/features.h" 2 3
> # 318 "/usr/include/features.h" 3
> # 1 "/usr/include/gnu/stubs.h" 1 3
> # 319 "/usr/include/features.h" 2 3
> # 26 "/usr/include/stdlib.h" 2 3
> # 1 "/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/include/stddef.h" 1 3
> # 213 "/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/include/stddef.h" 3
> 
> typedef unsigned int size_t;
> 
> extern void *malloc (size_t __size) __attribute__ ((__malloc__));
> char * malloc();
> 
> /* end of t1.c */
> 
> "t1.c" is compiled successfully to generate a ".o" file.
> 
> But if I remove all the "#" directives, following error message will
> be shown:
> 
> t1.c:22: conflicting types for `malloc'
> t1.c:21: previous declaration of `malloc'
> 
> 
> Therefore, it shows that "#" directives does affect compilation. Is
> that correct ?

The '#' directives can disable some warnings.  The '#' directives can
indicate when compiling a system header file (the 3 at the end of the
lines) and some warnings are suppressed in system header flies.

However, the '#' directives should not suppress an error like this.
It seems that you are using gcc 3.2.3, which is quite an old version.
There may have been a bug back then.

I tried your test case with the current compiler, and it does report
an error with the '#' directives.

Ian