#include search paths

[Richard A. O'Keefe]

In article <2899 at ingr.UUCP> crossgl at ingr.UUCP (Gordon Cross) writes:
>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

Quick reminder:  no, /usr/include/ is searched _last_ whichever form
you use.

>There seems to be some confusion between various documents I checked
>regarding this.
>     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!! :-)

I doubt that such was their intention.  The point is that every compiler
which supports the -I flag permits this kind of thing:

	cc jim.c -I.
where jim.c contains the line
	#include <fred.h>

According to all the UNIX manuals _and_ Harbison & Steele, this will look
for fred.h in the current directory first, and that's the directory
containing the source file.  In fact we can state this as a general rule
for UNIX C compilers:  if there is at least one -I option in the command
line and the first -I option is -I., the difference between ".." and <..>
disappears.