|#include what? DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-04-25)|
|Re: #include what? firstname.lastname@example.org (Russ Cox) (2006-04-26)|
|Re: #include what? email@example.com (Ian Lance Taylor) (2006-04-27)|
|Re: #include what? cfc@shell01.TheWorld.com (Chris F Clark) (2006-04-27)|
|Re: #include what? firstname.lastname@example.org (glen herrmannsfeldt) (2006-04-28)|
|Re: #include what? email@example.com (2006-04-28)|
|Re: #include what? cfc@shell01.TheWorld.com (Chris F Clark) (2006-04-30)|
|Re: #include what? DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-05-09)|
|From:||"Russ Cox" <firstname.lastname@example.org>|
|Date:||26 Apr 2006 01:13:11 -0400|
|Posted-Date:||26 Apr 2006 01:13:11 EDT|
> [The C standards say that the interpretation of the <filename> or
> "filename" in #include is entirely up to the implementation. My
> impression is that the de-facto standard on Unix systems is whatever
> cccp, the GCC preprocessor, does. -John]
For #include <foo> gcc searches the -I directories you've specified,
then the standard system include directories.
For #include "foo" gcc searches the directory containing the current
file and then falls back to the <foo> rules.
There are various subtleties that no one should ever want to know
about some -I options that gcc accepts, but the above is the basics
that you can depend on from most compilers. As Join pointed out,
the C standard doesn't say anything about where to search,
but it does require that "foo" searches fall back to <foo> if whatever
early extra searching "" implies doesn't turn anything up.
#includenext, which is even-more gcc-specific, makes gcc start the search
where the search for the current file left off. This way you could
create your own wrapper around (say) <stdio.h> that was actually
called stdio.h and did something like
Using includenext keeps gcc from finding the current file again.
I can't imagine why you would ever use this.
Return to the
Search the comp.compilers archives again.