Date: Sun, 5 Feb 1995 10:23:06 -0500 (EST)
From: Chris Tate <FIXER AT FAXCSL DOT DCRT DOT NIH DOT GOV>
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: #include <sys/....> notation

'Twas written:

>>>It's not supposed to.  The source would have #include <sys/...h> in
>>>it.
>>
>> ... except that "#include <sys/...>" is nonportable.  :-P
>
>Why not?  Does the forward slash confuse you?  If it does, then
>don't be worried: I have yet to see a C compiler which doesn't
>understand it, even if the host OS directory separator character
>is different.  In fact, the *only* portable way to give
>pathnames in #include directives is with the forward slash.

It is decidedly *not* portable.  ANSI doesn't say that <sys/....>
notation has to be processed as subdirectory specification; in fact,
the whole notion of how to support headers in subdirectories is
implementation-defined - and therefore *inherently* nonportable.
What about platforms where the '/' character is perfectly legal as
part of a file name?

There are at least two major Mac compilers that don't support the
notation; they doesn't need it.  They scan subdirectories of the system
tree for #include <foo.h> automatically, and will find foo.h anywhere
in the compiler's "system includes" directory tree.  That's the approach
taken by many compilers for the Mac; for my part, I find it far easier
to deal with than using, say, environment variables to control searching
for included files.

I believe ANSI mandates the names and contents of header files; doesn't
it say that the canonical form is <types.h> instead of <sys/types.h>,
for example?  Or is that not an ANSI header?

An example of this is the Rogue Wave tools; they tend to "insist" that
their headers be included via the notation #include <rw/foo.h>.  On the
Mac, that means they supply a header file called "rw/foo.h" - the slash
is part of the filename.

-- Chris Tate
   fixer AT faxcsl DOT dcrt DOT nih DOT gov