Casper.Dik at sun.com wrote:
> This seems wrong; personally I think we should rip out any replacement
> for system libraries; such duplication leads to more code which needs
> to be maintained. This includes replacements for <stdio.h>.
You are looking from the wrong point....
You are looking from the viewpoint of a person that only needs to support
a single platform.
If you write highly portable programs, the other way round id true.
All my programs (including cdrecord and star) are linked against libschily.
Libschily is a lib that implements add-ons to stdio and that implements it's
own printf. It turns out, that this results in cleaner code and less problems
once you did implement enough features and abstraction.
> (The problem is even bigger if these are indeed shipped as part of
> the ksh libraries; having multiple implementations visible to processes
> is bad; note that re-exporting symbols like fopen() would be blatantly
> illegal in C and therefor also in Solaris; our libraries will malfunction
> when they find a different stdio library)
I didn't check how sfio is implemented, but doig it the right way will not cause
problems. Note that there is a weak symbol fopen() and a non-weak _fopen().
Libschily implements a "fileopen()" that lives besides fopen().
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
