Mail Archives: djgpp/1995/02/06/18:44:06
In article <950205102306 DOT 20403e85 AT faxcsl DOT dcrt DOT nih DOT gov>,
Chris Tate <FIXER AT FAXCSL DOT DCRT DOT NIH DOT GOV> wrote:
>'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?
Such as Acorn's RISC OS, which uses '.' as directory separator? And '/' is
commonly used as a 'pseudo-extension', for example, by the DOS disk reader.
Well, of the 3 RISC OS C compilers I know of, I know first-hand that two
interpret '/' as directory separator in #include-s, and I've heard the other
does too.
>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?
It's not an ANSI header, it's a Unix one. It makes sense for any compiler
which has a Unix work-alike library to support this convention, as it means
Unix code has a good chance of compiling without having to nest a mess of
#ifdef-s around most #include-s.
Olly
--
Putting the "Ol" in technology.
- Raw text -