#include search paths
Gordon Cross
crossgl at ingr.UUCP
Sat Nov 12 01:15:05 AEST 1988
In article <1866 at loral.UUCP>, jlh at loral.UUCP (Physically Pffft) writes:
> When I have a line like '#include <fred.h>' I was under the impression
> that /usr/include was searched for fred.h first due to the use of <> instead
> of quotes. Is this true? And where did I get this idea?? Now that I need
> to verify it I can't find squat that tells me the difference between <> and
> quotes.
There seems to be some confusion between various documents I checked
regarding this.
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? I will come back to this later. The document goes on to say that
if the aformentioned capability "is not supported, or if the search fails,
the line is reprocessed as if it read [ <filename> form ]." Regarding the
<filename> form the standard only states that the preprocessor "searches
a sequence of implementation-defined places". Well, nothing very
concrete here but it seems to agree with your assumption regarding
<fred.h>! Seems like the definition of a non-standard to me! :-) :-)
2) A very good book on the C language, "C: a Reference Manual" by Samuel
P. Harbison and Guy L. Steele Jr. does say a bit more. 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". On the <filename> form,
Harbison & Steele say that it "typically does *not* search for the file
in the same directory in which the file containing the #include command
was found, but only in certain standard places according to implemen-
tation dependent search rules." This word "typically" would seem to
allow <fred.h> to be searched for like "fred.h" should the compiler
writer wish it. Hummm, so far we seem to be up the proverbal creek
without the required paddle!! :-)
3) Let's see, getting more implementation-specific I checked the UNIX
System V Programmer's Reference Manual which says that the "filename"
form "will be searched for first in the directory of the file with the
#include line, then in directories named in -I options, and last in
directories on a standard list." Neither of the other two documents
mentioned the -I options!! And I thought of these as being a de-facto
standard... Regarding the <filename> form it says "the directory of
the file with the #include line is not searched." Okay I guess this
means that it *does* search first in directories listed on -I options
and lastly in the "standard" place(s). Does -I change where your
compiler looks first for <fred.h>??
4) Alright time to punt; I checked Kernighan & Ritchie. Regarding the
"filename" form I quote: "The named file is searched for first in the
directory of the original source file, and then in a sequence of
standard places." On the <filename> form, K&R state that it "searches
only the standard places, and not the directory of the source file."
OK, K&R agree with your intrepretation of <fred.h>.
Overall conclusion: experiment. You are in the same boat I've been many
times -- when in doubt and documentation is lacking or conflicting, play with
it!! You can usually find your (implementation-specific) answers in this
fashion. Good luck!!
Gordon Cross
Intergraph Corp. Huntsville, AL
More information about the Comp.lang.c
mailing list