Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl From: karl@haddock.ISC.COM (Karl Heuer) Newsgroups: comp.lang.c Subject: Re: Leo's ANSI C Flame Summary: A conforming implementation can still have extensions Message-ID: <5164@haddock.ISC.COM> Date: 15 Jul 88 02:00:38 GMT References: <2258@sugar.UUCP> <225800045@uxe.cso.uiuc.edu> Reply-To: karl@haddock.ima.isc.com (Karl Heuer) Organization: Interactive Systems, Boston Lines: 51 In article <225800045@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >>>and with, probably, a bit of name-space pollution. >>Whatever for? It's simple enough to avoid. >Backward compatibility. Buyers will scream bloody murder if a vendor's >new compiler won't compile programs their old one did. Remember memmove. (See below about namespace.) What about memmove? I don't see the connection. >>>Most compilers will require a special command line switch to get full >>>compatibility with the standard. > >>...Perhaps you mean that most compilers will require a special option to >>disable all extensions and compile only strictly conforming programs? > >This is exactly what I meant. I am of the understanding that it will >be very difficult to come up with "conforming" extensions other >than by adding functions that begin with an underscore. Do you mean >to say that, for example, added keywords like "far" or "near" >or "asm" or "pascal" will be allowed? Okay, we have two types of namespace pollution here. I wasn't thinking of non-standard keywords (the compiler I normally use doesn't have any except asm, which I don't use); you're probably right that Microsoft will keep these as a non-conforming extension. It is possible, though, to support additional functions without colliding with the user's namespace. For example, the nonexistence of a read() in ANSI C implies that #includeint read(void) { int n; scanf("%d", &n); return n; } int main(void) { printf("%d\n", read()); return 0; } is a strictly conforming program; an ANSI compiler is obliged to compile it as if it had never heard of the UNIX read() system call. However, int main(void) { char buf[2]; read(0, buf, 2); return (buf[1]); } is a valid UNIX program, which (I claim) can be correctly compiled by a fully- -conforming ANSI C compiler on UNIX (or POSIX). One simple way to do this is to let libc.a have an entry point _sys_read(). Any ANSI functions which require the system call invoke it by this internal name. A separate library libposix.a contains the function int read(int fd, char *buf, int n) { return _sys_read(fd, buf, n); } which the user is allowed to call. When the compiler is invoked with its default options, both libposix.a and libc.a are loaded. For strictly conforming programs, there won't be anything to find in libposix.a. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint ________ For simplicity, I've written the above as if the correct prototype were int read(int, char *, int); which may not be right. I haven't checked the POSIX specs, but I wouldn't be surprised if it uses size_t.