ksh93, sfio and portabilty / was: Re: [ksh93-integration-discuss] comments on rev 287 makefiles

[Glenn Fowler]

> And while stdio has many shortcomings, it's what we have, know and love to
> hate.  I don't think we want the AST stdio wrappers available for public
> consumption because this will always lead to confusion of the form
> "X bug in stdio" "can't reproduce", "oh, but we used AST stdio".

the main issue is what public entities the ksh executable will require
if ksh = a.out + libshell.so + ast .so's
then the distribution must decide if libshell.so + ast .so's are
there for only the runtime or for both runtime and development
(development meaning compiling/linking against the .so's)

if for development then the headers compiled against better jive
with the original headers compiled against or no-one will be able
to debug the ensuing mess

since <ast/stdio.h> is not used by ast applications/libraries
its not a big deal except that if <ast/stdio.h> is not advertized
for libast.so development then solaris will need a caveat for
ksh builtin developers to use <sfio.h>, not <stdio.h>

> We may not "demand" the removal of the portability layers in Mozilla
> (Netscape Portable Runtime or some such), but we now that it a pile of junk
> and we know that such compatibility layers are best avoided.

a veiled inference to the ast portability paradigm?