Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: #include search paths
Message-ID: <1988Nov13.011054.23413@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1866@loral.UUCP> <2899@ingr.UUCP>
Date: Sun, 13 Nov 88 01:10:54 GMT

In article <2899@ingr.UUCP> crossgl@ingr.UUCP (Gordon Cross) writes:
>  1) the proposed ANSI standard says that the "filename" form "is searched for
>     in association with the original source file".  What exactly does this
>     mean?  ...

You are reading an obsolete draft.  The May draft (which is still the latest)
just says "searched for in an implementation-defined manner".  This arises
from a combination of historical differences in compilers and the problems
of describing a file system in a system-independent way.

>     ... Regarding the
>     <filename> form the standard only states that the preprocessor "searches
>     a sequence of implementation-defined places".  Well, nothing very
>     concrete here...

Again, it's difficult to be concrete in an implementation-independent way.
Note that the <foo.h> form is specifically *not* required to refer to a
*file* at all -- the headers might even be built into the compiler.

>     ... Regarding the
>     "filename" form, Harbison & Steele state that the precessor "typically
>     searches for the file first in the same directory in which the file
>     containing the #include command was found, and then perhaps in other
>     places according to implementation dependent search rules."  Well,
>     perhaps this is what the standard was referring to with the statement
>     "in association with the original source file"...

That and other variations.  Note that "in association with the original
source file", which is more or less K&R1 wording, is *NOT* the same as
"same directory in which the file containing the #include was found" --
if you nest #includes, "original source file" and "file containing
the #include" are not the same file!  Different compilers handle this
in different ways, which is one reason for X3J11 vagueness.

>     ...  Neither of the other two documents [X3J11, H&S]
>     mentioned the -I options!!  And I thought of these as being a de-facto
>     standard...

Only on Unix and Unix-like systems.  Those documents are trying to describe
*C*, not the form of options for a particular C compiler.
-- 
Sendmail is a bug,             |     Henry Spencer at U of Toronto Zoology
not a feature.                 | uunet!attcan!utzoo!henry henry@zoo.toronto.edu