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