ANSI C standard library
Chris Torek
torek at elf.ee.lbl.gov
Sun Apr 21 10:39:04 AEST 1991
>lewine at cheshirecat.webo.dg.com (Donald Lewine) writes:
>>If there is [an ANSI C] library that is 60% ANSI conforming C,
>>you are doing very well.
In article <677 at taumet.com> steve at taumet.com (Stephen Clamage) writes:
>This is simply untrue.
Well, the percentage is off, but...
>We have a complete hosted ANSI C library written in ANSI C ...
>[with `about 10' system support calls].
>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%.
Just for comparison: the `free' BSD project has gotten fairly far along
in terms of the C library. I ran the following commands:
% tar cfFF - hp300 | wc
4640 31024 233472
% tar cfFF - i386 | wc
2393 15243 122880
% tar cfFF - vax | wc
5767 35098 253952
% tar cfFF - tahoe | wc
6102 34337 253952
% tar cfFF - db gen locale net stdio stdlib string sys | wc
85910 371098 2564096
(the undocumented capital-FF skips SCCS and RCS files). This gives an
`overall' library ratio of about 5-to-10 percent machine dependent
code, depending on the machine (lower on the Intel-386, primarily due
to lack of tuning)---but this value is affected by several things:
A. The library includes POSIX and BSD functions as well as `pure' ANSI
C functions.
B. There are `semiportable' versions of all of the string functions in
the portable code, with CPU-specific versions in the machine
directories. Thus memcpy is counted once in `string' and once in
`tahoe/string', for instance.
C. The math library, which *should* be largely machine-dependent (for
performance reasons), is not included above. Adding them in:
$ for i in [a-n]* tahoe vax
> do
> echo $i; tar cfFF - $i | wc; done
common
780 4063 32768
common_source
5927 29102 208896
ieee
960 4608 36864
mc68881
1433 8765 65536
national
854 3972 24576
tahoe
830 4792 32768
vax
1951 9572 65536
will require more analysis than I am willing to do here, because again
there are many functions that have `semiportable' versions and rely on
underlying pieces.
and of course
D. `tar' throws the numbers off a bit. (It was just a convenient way of
not counting the revision control data.)
--
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA Domain: torek at ee.lbl.gov
More information about the Comp.std.c
mailing list