randy@umn-cs.cs.umn.edu (Randy Orrison) (01/10/88)
In article <7013@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: | |> if (ptr = strchr (str,'\')) { | |This is, has been, and will continue to be a correct way to test |for a null pointer. However, '\' is nonportable. A couple things: -- '\' is not nonportable, it's illegal (no?) since it's an escaped single quote, preceeded by a single quote, but not followed by one (should be "strchr (str,'\\')" or "strchr (str,'\'')" whichever he meant. -- Assuming that what was really meant was '/' for parsing Unix pathnames, this would be called nonportable, and there's the reason for this message. Since ANSI C is intended to maximize portablility of programs, and since programs that deal with files in anything but the current directory must specify pathnames (if such are available), does dpANS include any provision for portable handling of paths? I'm thinking of standardized library routines that would build paths for you, in whatever the native syntax is. Has this been considered? Or, is this too much an operating system thing and not a C language thing? -randy -- Randy Orrison, University of Minnesota School of Mathematics | UUCP: {ihnp4, seismo!rutgers, sun}!umn-cs!randy | (hello?) ARPA: randy@ux.acss.umn.edu BITNET: randy@umnacca | (Applications currently being taken: short text, for last line of .sig)
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/11/88)
In article <3474@umn-cs.cs.umn.edu> randy@umn-cs.UUCP (Randy Orrison) writes: > -- '\' is not nonportable, it's illegal I was actually thinking of an obscure interpretation of "implementation- defined", but it isn't unless there is another ' somewhere later on the line. Clearly what was intended, however, was miscoded. >Since ANSI C is intended to maximize portablility of programs, Within reason! We cannot constrain operating systems unduly; that's beyond the scope of X3J11. >..., does dpANS include any provision for portable handling of paths? No, because some important OSes don't have hierarchical file systems. The best we could do was to define some guaranteed minimalistic filenames for use with #include "", and even that took a lot of discussion and negotiation with people having difficult OSes. >Or, is this too much an operating system thing and not a C language thing? Exactly. Note that the proposed IEEE Std 1003.1 (POSIX) specifies some things about pathname syntax and semantics for UNIX-like systems.