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