ANSI C standard library

[Colin Plumb]

>> In article <1991Apr11.185038.108 at cpqhou.uucp>, pipkinsj at cpqhou.uucp (Jeff Pipkins @Adv Dev at SE hou ) writes:
>>> I'm looking for an ANSI C implementation of the ANSI C standard library...

> lewine at cheshirecat.webo.dg.com (Donald Lewine) writes:
>> It can not be done!  The reason that many of these things are in
>> the ANSI library is that they can not ve written in portable C.
>> If there is a library that is 60% ANSI conforming C, you are doing
>> very well.

steve at taumet.com (Stephen Clamage) wrote:
> This is simply untrue.  (Those who say a thing cannot be done should
> stay out of the way of those who are doing it...)
>
> We have a complete hosted ANSI C library written in ANSI C.  It depends
> on operating system support (system calls) for those features which
> interact with the operating system.  There are about 10 of these calls.
> If a system does not provide the support, the C library features are
> not available anyway (how do you open a file if there is no file system
> and no "open-file" system call?).
>
> There is one assembler source file for ANSI C functions: setjmp/longjmp.

Okay, time to start in on the language legalese.
A "strictly conforming" program obeys all the rules of the ANSI C
standard.  A "conforming" compiler will compile all strictly conforming
programs (subject to limits like memory usage).  A "conforming" program
is one that is accepted by a conforming compiler.  It may use any extensions
the compiler wishes to provide, as long as those won't foul up strictly
conforming C programs.  Most of gcc's extensions fall into this category.

Anyway, it's easy to write a reasonably portable, conforming C library.
That is, one that will compile on a number of ANSI-conformant C compilers
and work as intended.  There are however, a number of functions in the
C library that cannot be implemented, efficiently or perhaps at all, in
*strictly* conforming C.  setjmp/longjmp is the obvious one.  memmove is
the standard example of somethig that's doable in strictly conforming
ANSI C, but not efficiently.  The problem with memmove is that you have
to handle overlapping properly, and comparisons between pointers into
different objects are not guaranteed comparable by the relational
(<, <=, >, >=) operators in ANSI C.  Thus, you have to use equality
tests (which are guaranteed to work) to check to see if any byte in the
source is also a byte in the destination.

This is, of course, disgusting, and nobody would actually write it that way.
But the reason for those odd guarantees is that they simplify doing far
pointer arithmetic on 80x86 machines, and so have some very common
applications.  (True, there the relational operators will just gove bogus
results on pointers to different objects, which doesn't hurt much, but
some hypothetical fascist capability machine might give a run-time error.)

So, the upshot of it all is:
- A large fraction of the ANSI C library can't be written in *strictly
conforming* ANSI C.  This was usually the reason of putting it in the
library in the first place - without the library function, the programmer
would be up the creek.  Thus, if you want a strictly conforming (guaranteed
to work on any ANSI C compiler) C library, you're out of luck.
- However, most people's ANSI C libraries are mostly or even wholly
C.  It's just that it's not strictly conforming C, as it relies on
certain properties of the compiler that are not guaranteed by the ANSI
C standard.  If you're willing to live with extra constraints, there
are a number of non-strictly conforming C libraries floating around
(admittedly mostly commercial).

Is that fairly clear?
-- 
	-Colin