On 10 September 2007 20:37, Eli Zaretskii wrote:
>> Date: Sun, 9 Sep 2007 21:40:38 -0600
>> From: "Philip Guenther" <[EMAIL PROTECTED]>
>> Cc: [email protected]
>>
>> In my experience, C
>> compilers in UNIX search the directory of the source file, whether or
>> not that directory is named in a -I option.
>
> Only if you say `#include "foo.h"', not `#include <foo.h>'. The C
> standard specifies that "foo.h" is looked for in the current directory
> first.
This is not correct, AIUI, although it's a common misapprehension. In
traditional C89 days, perhaps, but for a long time now the standard has
nothing to say on any difference between #include ".." and #include <...>
except that they are implementation-defined. See 6.10.2:
2 A preprocessing directive of the form
#include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header identified
uniquely by the specified sequence between the < and > delimiters, and causes
the replacement of that directive by the entire contents of the header. How
the places are specified or the header
identified is implementation-defined.
3 A preprocessing directive of the form
#include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source
file identified by the specified sequence between the " delimiters. The named
source file is searched for in an implementation-defined manner. If this
search is not supported, or if the search fails, the directive is reprocessed
as if it read
#include <h-char-sequence> new-line
with the identical contained sequence (including > characters, if any) from
the original directive.
cheers,
DaveK
--
Can't think of a witty .sigline today....
_______________________________________________
Help-make mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-make
