Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn
From: gwyn@smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: stdio EOF
Message-ID: <8459@smoke.ARPA>
Date: 8 Sep 88 06:07:11 GMT
References: <813@ms3.UUCP> <1246@mcgill-vision.UUCP> <669@super.ORG> <8422@smoke.ARPA> <13427@mimsy.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 22

In article <13427@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>In article <8422@smoke.ARPA> gwyn@smoke.ARPA (Doug Gwyn ) writes:
>>... In fact [stdio] EOF should not be "sticky"; if more data becomes
>>available, as on a terminal, it should be available for subsequent
>>reading.  The 4.2BSD implementation broke this but it might be okay
>>on 4.3BSD.
>I thought this behaviour was added to 4.2BSD to conform to some
>existing standard.

No; it was added because Bill Shannon thought it was a good idea.
I noticed it because it broke several interesting applications.

>What does the dpANS say?  POSIX?

Remember that the C dpANS does not address multitasking issues
(where a file can grow due to other concurrent processes), nor
does it specify much about "terminal" device behavior.  I recall
the 4.2BSD sticky-EOF behavior coming up in dicsussion and not
finding any demurrers when it was labeled "bogus", but I also
doubt that it is explictly ruled "nonconforming".

I don't remember seeing this specific issue addressed by 1003.1.