[ note that i've expanded the cc list some... ]

>When I compile a function (under NetBSD/Alpha) like ....
> 
>----------------------------------------------
>#include <stdio.h>
>int main()
>{
>    return(0);
>}
>----------------------------------------------
> 
>with the command...
> 
>cc -c -Wall testx.c
> 
>I get a clean compile (no warnings).
> 
>When I use the command...
> 
>cc -c -Wall -nostdinc -I/usr/include testx.c
> 
>I get the following warning...
> 
>/usr/include/stdio.h:335: warning: `__sputc' defined but not used
>
>[ ... ]
>
>When I do the same thing under NetBSD/i386 I don't get the warning and I don't
>get __sputc in the object module. This seems like the _correct_ behavio[u]r.

I don't know why you're getting the .text entry, but:

> Is this a problem with gcc? Chris, does your new compiler do the same thing?

Yes, the new compiler does the same thing, and, looking at the
compiler sources, it's a "feature."  (grep -i around the gcc sources
for "in_system_header".)


if you run cc -E rather than cc -c on the files, and compare the cpp
output, you'll note that the line directives have a trailing:
	" 3"
added if the files come from the builtin include path.

i.e. if you compile normally, a line directive might look like:

# 1 "/usr/include/stdio.h" 1 3

whereas if you compile with -nostdinc -I/usr/include, then they'll
look like:

# 1 "/usr/include/stdio.h" 1


that trailing "3" means "this was a system include file."  gcc then
uses this to suppress certain warnings (e.g. some 'long long'
warnings, obviously that "unused function" declaration, etc.), and
obviously does a few things differently based on that flag.

Thinking about it, it's not clear whether, on a system such as NetBSD:
	(1) recognition of that flag should be suppressed (so that
	    files compiled with -Wall are _really_ completely
	    checked), or
	(2) by default, the system should be compiled with
		-nostdinc -I/usr/include


thoughts?



chris