/usr/include/ast/stdio.h - awful ? / was: Re: [ksh93-integration-discuss] comments on rev 287 makefiles

[Roland Mainz]

James Carlson wrote:
> Felix Schulte writes:
> > On 6/25/06, Casper.Dik at sun.com <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>.
> > There would be no need to replace it if the stdio implementation in
> > Solaris would be sane, however since it sucks a faster, non-sucking
> > replacement would be cool.
> 
> In that case, the right answer is to remove the "sucking" part of the
> Solaris stdio.  Since stdio is part of Open Solaris, this is doable.
[snip] 
> Forking off and restarting is not proper maintenance.

See my other posting
(http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-June/000454.html)
about what the /usr/include/ast/stdio.h header is for. libast's "sfio"
I/O functioanlity is very different from stdio for a couple of reasons.
On top of that a "compatibilty" layer was added to emulate some of the
stdio API behaviour.

> > > (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)
> > No, they won't malfunction. All AST stdio symbols have an '_ast_'
> > prefix in their ELF name, for example fopen() is listed as _ast_fopen
> > by elfdump
> 
> That doesn't make it any less awful.

Uhm... why ?

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)