Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!spool.mu.edu!sdd.hp.com!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Which C library to start hacking?
Message-ID: <1992Sep24.194515.2603@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <kjb.717312886@godzilla.cgl.citri.edu.au>
Date: Thu, 24 Sep 92 19:45:15 GMT
Lines: 57
In article <kjb.717312886@godzilla.cgl.citri.edu.au> kjb@cgl.citri.edu.au (Kendall Bennett) writes:
>I am about to start doing a _lot_ of work on the standard C library for
>386BSD. Most of the stuff that I will be doing is checking things for
>Standard/ANSI C conformance and POSIX 1003.1 conformance, but I will
>also be pulling every trick I know out of the book to make it run
>efficiently (this includes re-writing all the string handling routines
>in optimised assembler).
>
>Before I start doing this work I need to know which library to start
>working on. Should I begin work on the standard C library that comes
>with 386BSD, or should I use the GNU C library as the starting point.
>I have heard that the GNU C library has lots of bugs in it, so maybe
>this would not be a wise starting point.
There is a book (by Plauger?) from Prentice Hall on the C library, with
a large majority of the functions implemented. I would hazard a guess
that this is publically usable. I think it's something like "The UNIX
C Library" or something similar. I saw it in Software Plus.
This, in my opinion, would be the place to start. THe main problem with
the GNU library is potentially hairy (but as yet untested) potential
restrictions on the code using it.
I would also suggest using "-s" code from the output of the C sources
as a base for the "hand-coded" versions of the library routines -- in
particular, you would hand-optimize this code. That way the code is
still portable to other machines and can be hand-optimized for each new
architecture the code is ported to (rather than requiring a rewrite for
each new machine, at worst, or an asembly-to-assembly translation, at best.
Most of the POSIX behaviour is mandated at the system call interface and
the kernel subsystem implementation (for instance, the v_rdwr routine
is replaced with vn_read and vn_write to avoid going recursive on the
writes when the file system is changed for POSIX compliance). A whole lot
of this is at the syscall and syscall-to-VFS or VFS-to-file system layer
(for instance, the mandating of when files are marked for update).
Traditionally, especially in places like SunOS, the C library has been used
to provide system call wrapper functions to evidence a behaviour that the
kernel doesn't implement (or pre-checking or range validation on arguments,
etc.). I don't think this is really the case, or even a good idea for the
most part, any more.
Good luck on your project... this could be a real win!
Terry Lambert
terry_lambert@npd.novell.com
terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------