Path: utzoo!attcan!uunet!husc6!cmcl2!rutgers!apple!bloom-beacon!bu-cs!purdue!decwrl!sgi!arisia!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: #include search paths
Message-ID: <663@quintus.UUCP>
Date: 11 Nov 88 05:12:08 GMT
References: <1866@loral.UUCP>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 28

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.

Checking CPP(SD_CMD) in the System V Interface Definition, on p330 of
Vol 2 we find the description of the -I flag (paraphrased):

	A file whose name starts with / is taken as it stands,
	whether #include </dir/file.h> or #include "/dir/file.h".
	Otherwise:

	#include "file" will look
	- first in the directory of the file containing the #include line,
	- for each "-I<directory>" in the command, in that directory,
	  in the order in which the -I arguments appeared in the command, 
	- finally in directories on a standard list (/usr/include).

	#include <file> will not look in the directory of the file
	containing the #include line, but is otherwise just like "file".

"man 1 cpp" on a SunOS 3.2 system agrees.
So /usr/include is searched LAST in both cases.  The difference between
#include "stdio.h"	and
#include <stdio.h>
is, according to these manuals, just that the former will first look for
a ./stdio.h, and the latter won't.