🚀 go-pugleaf

lewine@cheshirecat.webo.dg.com (Donald Lewine) writes:

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

>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.

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.

There are a very few assembler files which provide low-level machine
functions, such as detecting the presence of a math co-processor,
providing support for the debugger, and so on.

On some systems to which we port, the system calls are known by different
names or have different calling sequences than expected in the portable C
code.  In such cases, we provide a translation function, usually in
assembler for efficiency.

We have used our library on BSD Unix, System V Unix, VAX/VMS, MS/DOS,
CP/M, OS/9.  We have used in on a variety of computer architectures:
MC680x0, VAX, SPARC, MIPS, ix86, i8085, MC6809.  Some of our
customers have ported the library to other systems.

Considering there are over 150 functions in the library written in ANSI
C, and less than a dozen tiny functions which are machine-specific, I'd
say we do considerably better than 60%.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com