Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.lang.c
Subject: Re: Distorting fseek semantics
Message-ID: <6420@brl-smoke.ARPA>
Date: Sat, 12-Sep-87 15:56:35 EDT
Article-I.D.: brl-smok.6420
Posted: Sat Sep 12 15:56:35 1987
Date-Received: Sun, 13-Sep-87 08:39:09 EDT
References: <493@its63b.ed.ac.uk> <6061@brl-smoke.ARPA> <8560@utzoo.UUCP> <1129@bsu-cs.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 38

In article <1129@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>No such justification exists for crippling the beautiful and simple
>semantics of fseek that have been in use for many years.

Not only does such a justification exist, if you had read the Rationale
document before spouting off, you would know what it is.

	"Whereas a binary file can be treated as an ordered sequence
	of bytes, counting from zero, a text file need not map
	one-to-one to its internal representation (see \(sc4.9.2).
	Thus, only seeks to an earlier reported position are permitted
	for text files."

In other words, text files simply cannot be counted on to support the
UNIX byte-array model, for a variety of technical reasons that were
thoroughly discussed by X3J11 in the process of specifying fseek().

The reason for not requiring SEEK_END be supported for binary streams
is that many systems do not maintain an EOF mark (some use a ^Z byte
followed by all NUL bytes in the last allocated block, some don't even
have that much of a marker).  The Rationale doesn't seem to explain
this particular point; perhaps it should.

Of course, UNIX implementations of fseek() will provide additional
semantics, and POSIX requires this in a couple of ways (identity of
text and binary streams; fseek() inheritance of lseek() semantics).
It is not within X3J11's assigned scope to insist that only UNIX-like
operating systems are valid, even if the committee believed that.

By the way, the idea that UNIX-like semantics be guaranteed and the
C implementation be limited to supporting just one of several
available file types (for example, VAX/VMS text stream type) has been
declared by several vendors to be unacceptable to their customers.
I have no reason to doubt that.

The alternative to the weaker-than-UNIX specification of fseek() would
have been to not require it at all for ANSI C.  I hope it is obvious
that that alternative is considerably less desirable.