*BSD News Article 5584


Return to BSD News archive

Path: sserve!manuel!munnari.oz.au!goanna!escargot!minyos.xx.rmit.OZ.AU!rcskb
From: rcskb@minyos.xx.rmit.oz.au (Kendall Bennett)
Newsgroups: comp.unix.bsd
Subject: Re: Which C library to start hacking?
Message-ID: <rcskb.717422977@minyos.xx.rmit.OZ.AU>
Date: 25 Sep 92 12:09:37 GMT
References: <kjb.717312886@godzilla.cgl.citri.edu.au> <1992Sep24.194515.2603@fcom.cc.utah.edu>
Organization: RMIT Computer Centre
Lines: 59
NNTP-Posting-Host: minyos.xx.rmit.oz.au

terry@cs.weber.edu (A Wizard of Earth C) writes:

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

I have P.J. Plauger's book, but I will be using it only for ideas, and
not taking the code directly from it - you require a license to do this!
Yes, damn silly if you ask me, but it is a fact of life...

>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 gather the 386BSD library is not copy-lefted, but copyright by the
UC Berkeley right? So if I write code that uses the GNU C library, this
code must be Copylefted as well? Oh dear. I know this is the reason a lot
of people avoid using bison and prefer berkely yacc, so if this is the
case maybe I better avoid the GNU C lib altogether?

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

Ech! Sounds like a good idea, but you will end up having code that looks
like it was written by a compiler! Once you identify the areas that need
to be worked on, they need to be re-written from scratch for that 
particular architecture taking full advantage of the 386's native 
language. Believe me, even gcc will out-code most people if you do things
just like a compiler!

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

Well, I haven't got into the details of POSIX, and it wont be for a while.
I will start by simply getting everything up to ANSI/Standard C specs
and optimised, then I will work on the POSIX stuff. ANSI is a subset of
POSIX anyway, so this should not be a problem :-)

>Good luck on your project... this could be a real win!

Thanks...

+------------------------------------------+-------------------------------+
| Kendall Bennett,                         | Internet:                     |
| Advanced Computer Graphics Centre,       | kjb@godzilla.cgl.citri.edu.au |
| Royal Melbourne Institute of Technology, | rcskb@minyos.xx.rmit.oz.au    |
| Victoria, AUSTRALIA.                     |                               | 
+------------------------------------------+-------------------------------+
| CoSysop (Bossman), PC Connection Australia:               +61 3 688 0909 |
+--------------------------------------------------------------------------+