I heard that C's stdio is mostly unchanged from the initial form which was provided at Unix v7. For the example of non-blocking I/O, it was introduced in later than v7. So "UNIX Network Programming, Vol1" said mixing them is a recipe for disaster.
I don't know why perl-guys developed PerlIO, but I think there were probably such dark corners. It seems that also python 3.x has a new I/O system which doesn't use C's stdio. I'm searching its background to indulge my trivial curiosity now. 2010/9/30 Andrei Alexandrescu <[email protected]>: > On 9/29/10 17:45 PDT, Jonathan M Davis wrote: >> >> On Wednesday, September 29, 2010 17:36:34 s50 wrote: >>> >>> Oops, you already have mentioned about the lookahead things. >>> Sorry I overlooked it. >> >> Did you look too far ahead? ;) >> >> It's interesting to hear about Ruby's situation with c stdio though. > > I don't know about Ruby, but my experience with C++ and Perl suggests that > there are always some dark corners in any language's file I/O, inevitably > revolving around buffering and interaction with C. My speculation is that > all languages must implement their stuff on top of C's stdio, which has an > inadequate API. My big question is how come stdio has evolved so little and > so slowly; the file API is central to Unix. But then all programs that do > serious I/O go away from FILE* and use ioctl() et al. > > > Andrei > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos > _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
