"Donn Cave" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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.
I think you over interpreted. The ''s were intentional. Let me reword. If one if implementing a standard and it is *silent* on an initial condition then one must *choose* something (or let it be complete accident, and even possibly invalid). If there is one accessible and known existing 'standard' practice that is at least as reasonable as anything else, and the hole seems to be an accident rather than intentional, then I too would want to be that choice made. But if there are two existing 'standard' practices, then there is a real choice to be made. (But either would be better than a third.) > 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. The person I responded to gave almost none of this detail. With this info, and the knowledge that Berkeley got Unix from Bell Labs about 1975, I speculate that the hole of not specifying the initial read position was intentional due to divergent well-established prior arts that neither group wanted to give up. And yes, I also wish that someone had. I even wish the committee had at least specified 'either 0 or EOF' to preclude a Solomonic compromise like EOF//2. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
