ANSI C standard library

[Stephen Clamage]

There have been a number of postings and some private mail regarding my
comments that almost all of the ANSI C library can be written in
strictly-conforming C.  Only three functions have been identified as not
possible to write -- setjmp, longjmp, and (being VERY strict) memmove.

The comments challenging my statement generally confound the concept of
"strictly conforming" with "completely portable".  The two concepts
are not the same.

Strictly-conforming C code may call an external function not supplied
with the translation unit:
	extern int foo(void);
	main() { return foo(); }
This is a strictly-conforming translation unit.  It is not portable to
systems which do not provide a function foo().  It might produce
different results on different systems, depending on what the local
version of foo() does.

The standard also does not state that foo() must be written in strictly-
conforming C for this unit to be strictly-conforming.  If I wrote foo()
in some odd dialect of C, does it affect the conformance of the
main() unit?  If it did, then no C program could ever be strictly-
conforming, since at some point buried in the library, some amount of
machine-dependence is required.  How does main get started?  How does a
hosted implementation accomplish file I/O?  We must conclude that things
outside the translation unit cannot affect how we evaluate conformance.

By extension, foo() need not be written in C at all, so long as it
provides an interface callable by a C program with C's function-call
semantics (the "as-if" rule).

If as an implementor, I provide (for example) a <limits.h> containing
the line
	#define INT_MAX 0x7FFFFFFF
this is strictly-conforming ANSI C.  This macro definition is not usable
on all systems, since not all systems use 32-bit integers.  If I provided
an implementation for a 16-bit system, I would use a different version of
<limits.h>.  Each implementation has a version of <limits.h> which is
correct for that system, but which need not be portable to other systems.
-- 

Steve Clamage, TauMetric Corp, steve at taumet.com