Re: #include what?

Hans-Peter Diettrich <>
9 May 2006 00:52:08 -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: Hans-Peter Diettrich <>
Newsgroups: comp.compilers
Date: 9 May 2006 00:52:08 -0400
Organization: Compilers Central
References: 06-04-148 06-04-150 06-04-154
Keywords: C, standards
Posted-Date: 09 May 2006 00:52:08 EDT

Chris F Clark wrote:

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

A native development system may implement an appropriate structure as
well, so that a port to weird systems will not require too many
changes to the source code and makefiles.

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

Thanks for that hint! I already used a IncludeOnlyOnce flag, to
prevent further processing of already processed header files. Now it
might be a good idea to distinguish between <system> and "other"
header files, so that this flag only applies to system headers.

Other languages distinguish more explicitly between true "header"
files, containing invariant declarations, and "source" files, which
always have to be inlined.

BTW, #include_next IMO is part of cross-compiler support, where a
single header file can be split into an general part and OS and
machine specific parts. The include path then can be constructed from
--target and similar options, so that #include_next will search the
appropriate target specific directories.

Sorry for the late response, my machine broke and I've been offline
for a week.


Post a followup to this message

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