>Offtopic: Which still reminds me to write an email about that the >Solaris kernel is very very malloc()-happy (which is unneccesary in many >cases now that C99-sematics are allowed).
You are wrong. We *malloc* not because of shortcomings in C but because we don't have any room on the stack to put stuff. >The problem with this example is that it doesn't really fit. >ksh93/libshell have to run on many platforms (AFAIK far more than 30) so >an abstraction layer is needed (called "libast"). Otherwise the whole >shell code would be totally unreadable by gigantic amounts of #ifdef >stuff just to handle various differences between platforms. And part of >this "portability runtime" is an I/O library called "sfio". What is so >evil with this approach ? Almost every big project including >Mozilla/Firefox/Thunderbird, mysql, Gnome and Apache use the same path >and noone from Sun complained yet. If you've looked at them in any detail you'd know that these compatibility layers generally *are* evil; the code quality is poor, the code is baroque. And rather than coding to specific standards (say, pick a standard, and write a compatibility layer for those that do not implement said standard), these people invent their own compatibility layer. The net result is generally that we end up with a poor interface which is not well defined and which has several poor implementations each with its own set of bug. The maintenance hurdle is actually higher: for the people who wrote the code it may not seem so, but any such code requires you to learn yet another abstraction layer. This should not be taken as a critique on the quality of sfio or ast; it's just that the other examples you mention are, in our opinion, not cases where the right decision was taken. >Compared to the maintaince costs of handling each single platform >seperately in the libshell code ? ksh93/libshell still need to be >portable. Just because Solaris's stdio/libc functions are mainly >bug-free doesn't mean that all other plaftorms are in the same state. >Erm, please suggest an alternative then which still works on 30+ >platforms... Clearly, we're not dealing with 30 odd platforms in Solaris so our perspective is different. I think we just don't want the AST stdio wrappers exposed. But if ksh is not written to use stdio then that's not much of an issue. Casper
