| |
|
s50
Posted in reply to Andrei Alexandrescu
| 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 <andrei at erdani.com>:
> 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
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
|