Leo's ANSI C Flame

[Karl Heuer]

In article <225800045 at uxe.cso.uiuc.edu> mcdonald at 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
	#include <stdio.h>
	int 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 at 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.