In article <[EMAIL PROTECTED]>, "Terry Reedy" <[EMAIL PROTECTED]> wrote: ... > If there is a hole in the standard, 'innovation' is required.
I hope this perspective is a rarity. When you exploit an opportunity to make something work differently while conforming to the existing standards, you're creating the kind of problem standards are there to prevent. In the end I don't care if my software works because someone followed the standards to the letter, or because someone took the trouble to follow existing practice whether it was codified in a standard or not, I just don't want it to work differently on one platform than on another. Holes in standards are at best an excuse for accidental deviations. In the present case, so far I see a strong Berkeley vs. everyone else pattern, so GNU C probably wasn't the culprit after all. Along with already documented FreeBSD, I find MacOS X, NetBSD 2 and Ultrix 4.2 position the read stream to EOF. Linux, AIX and DEC/OSF1 (or whatever it's called these days) position it to 0. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
