Re: #include what?

Chris F Clark <>
27 Apr 2006 09:12:40 -0400

          From comp.compilers

Related articles
#include what? (Hans-Peter Diettrich) (2006-04-25)
Re: #include what? (Russ Cox) (2006-04-26)
Re: #include what? (Ian Lance Taylor) (2006-04-27)
Re: #include what? (Chris F Clark) (2006-04-27)
Re: #include what? (glen herrmannsfeldt) (2006-04-28)
Re: #include what? (2006-04-28)
Re: #include what? (Chris F Clark) (2006-04-30)
Re: #include what? (Hans-Peter Diettrich) (2006-05-09)
| List of all articles for this month |

From: Chris F Clark <>
Newsgroups: comp.compilers
Date: 27 Apr 2006 09:12:40 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 06-04-148 06-04-150
Keywords: C, standards
Posted-Date: 27 Apr 2006 09:12:40 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.

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

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

Hope this helps,

Chris Clark Internet :
Compiler Resources, Inc. Web Site :
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)

Post a followup to this message

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