🚀 go-pugleaf

In article <24992@dog.ee.lbl.gov> I wrote:
>>A number of existing implementations that claim POSIX
>>conformance (and hence ANSI X3.159-1989 conformance) do NOT always
>>append with "a+" mode; are they broken?

In article <Bs4vLp.A1y@jrd.dec.com> diamond@jit.dec.com (Norman Diamond) writes:
>I think that neither paragraph overrides the other.  If the program obeys
>the standard's requirements, then all writes will be appended to the end
>of the file.

Thus, these implementations *are* broken.  An example program fragment:

	fp = fopen(name, "a+");
	...
	rewind(fp);
	ret = fwrite(...);	/* replace record at offset 0 */

As the comment says, the author expected this `fwrite' call to overwrite
the first few bytes in the file.  On these existing implementations, it
*does*, even though the file is considerably longer.

(This was the question.  I am not sure if your answer above is meant
to say that "yes, these implementations are broken".  To name names:

    "HP and DEC are certified to have passed POSIX P1003.1 testing and HP
     runs an NIST approved POSIX P1003.1 testing facility. ..."

yet these same systems make the above fwrite write at other than EOF.)

>If the program does not obey the standard's requirements, then the
>results are undefined.

Certainly; that was never the question.

>>(As an aside, I have an existence proof that the intermediate seek
>>`feature' is unnecessary, in the form of the 4.3BSD-net.2 stdio.

>No.  An example of an implementation with an extension does not prove
>that programs don't have to obey the standard.

That is NOT what I meant.  I meant that the historical justification
(`ANSI C requires the seek because you have to seek to reset fp->_cnt')
is ONLY historical; it has no basis in sensibility.  (`Historical'
reasons are certainly good enough for a standard, though given that the
ANSI committee saw fit to fix other existing bugs, I am not sure why
they balked at fixing this one.)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov