Path: utzoo!attcan!uunet!ingr!crossgl
From: crossgl@ingr.UUCP (Gordon Cross)
Newsgroups: comp.lang.c
Subject: Re: #include search paths
Summary: #include requires Sherlock Holmes!!
Message-ID: <2899@ingr.UUCP>
Date: 11 Nov 88 15:15:05 GMT
References: <1866@loral.UUCP>
Organization: Intergraph Corp. Huntsville, Al
Lines: 63

In article <1866@loral.UUCP>, jlh@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