To: djgpp AT sun DOT soe DOT clarkson DOT edu Path: mantis!not-for-mail From: olly AT mantis DOT co DOT uk (Olly Betts) Newsgroups: mail.djgpp Subject: Re: #include notation Date: 6 Feb 1995 19:46:05 -0000 Organization: Mantis Consultants Ltd, Cambridge, UK Lines: 41 References: <950205102306 DOT 20403e85 AT faxcsl DOT dcrt DOT nih DOT gov> In article <950205102306 DOT 20403e85 AT faxcsl DOT dcrt DOT nih DOT gov>, Chris Tate wrote: >'Twas written: > >>>>It's not supposed to. The source would have #include in >>>>it. >>> >>> ... except that "#include " 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 >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 instead of , >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.