Re: #include what?

> [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.


Following what gcc does is certainly a good model. And it is true
that the C standard is intentionally vague about what the search rules
mean. This is because in certain circumstances the machine/OS on
which the compiler is being run may have no concept of directory (at
least not like the Unix/Windows/Mac world knows about it). Note, I
have never programmed on such a system, nor even know if such things
actually exist.


By the way, the standard was specifically designed so that #include
<xxx> need not reference any actual include file at all, and might be
just some symbol table entries built-into the compiler. In theory
this model was espoused by Algol-68, which had a "standard library
prelude" which could either be something the compiler read or
something built-into the compiler.


Next, you seem to have some confusion about what "current directory"
means. If you've lived in a GUI world most of your life, that might
not be surprising.


Generally, "current directory" now means, the directory containing the
file which has the #include statement inside it. That is if you have
a source file called "/source/text.c" that has done an include of
"foo.h" and that has gotten resolved to "/include/lib/foo.h", then the
current directory for #include statements within foo.h is
"/include/lib/" and for #include statements in "text.c" is "/source/".


However, this was not always the case. In the pre-gui days, when
everyone did command line programming in something akin to a "shell".
The OS/shell kept a concept of the "current directory" (originally in
Multics it was called the "current working directory") and all file
system commands that didn't specify a complete path (i.e. "foo.c" as
opposed to "/source/foo.c") were resolved as references in (or
relative to) that current directory. I find it amusing that
"shorcuts" (which are Windows version of executable soft-links) allow
one to specify a working directory, so that old programs which use the
"OS" relative directory concept have a directory that users can
choose.


It is worth noting that various compilers interpreted the concept of
"current directory" differently, with some using the modern concept
(the current directory is the directory containing the text that I am
currently processing) or variations on that theme, like the current
directory is the one which holds the original source file I started
processing, or the traditional version where the OS keeps the "current
directory".


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)

Return to the comp.compilers page.
Search the comp.compilers archives again.