Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.std.c
Subject: Re: ANSI C standard library
Message-ID: <12320@dog.ee.lbl.gov>
Date: 21 Apr 91 00:39:04 GMT
References: <1991Apr11.185038.108@cpqhou.uucp> <1991Apr15.194430.18673@webo.dg.com> <677@taumet.com>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 74
X-Local-Date: Sat, 20 Apr 91 17:39:04 PDT

>lewine@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@taumet.com> steve@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@ee.lbl.gov