Mail Archives: djgpp/1995/02/05/11:26:20
'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
- Raw text -