Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.lang.c
Subject: Distorting fseek semantics
Message-ID: <1129@bsu-cs.UUCP>
Date: Thu, 10-Sep-87 12:41:52 EDT
Article-I.D.: bsu-cs.1129
Posted: Thu Sep 10 12:41:52 1987
Date-Received: Sat, 12-Sep-87 09:07:55 EDT
References: <493@its63b.ed.ac.uk> <6061@brl-smoke.ARPA> <8560@utzoo.UUCP>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 38

In article <8560@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>Stdio includes fread, fwrite, and fseek.  The X3J11 drafts do
>put some restrictions on portable uses of them, which are inevitable given
>that the full generality of something like Unix seeks is unimplementable
>on some systems.

I realize I'm in the minority, but ANSI did something wrong here.  ANSI
is supposed to be standardizing an existing language.  Even the drastic
new feature of function prototypes is (a) upward compatible with all or
most existing software and (b) widely believed to be badly needed.  No
such justification exists for crippling the beautiful and simple
semantics of fseek that have been in use for many years.

ANSI had a simple choice:  (a) Leave fseek as it is, with the result
that some vendors would not be able to honestly claim conformance with
the ANSI standard until they modified their operating systems to
support a generalized seek;  (b) Change fseek so such vendors would not
have to work so hard.

The portability argument is a red herring.  ANSI is free to add an
appendix that describes a weaker fseek, in which one cannot directly to
go where one has not sequentially gone before, that nonconforming C
implementations can provide.  Software developers who really want to
support all systems, including the ones whose developers refuse to fix
their punched-card-based designs, could restrict themselves to this
weaker specification.  The rest of us would be able to write programs
as we've been writing them for a decade without being accused of not
conforming to ANSI specs.

C compilers for, UNIX, MS-DOS, AmigaDOS, Macintosh, CP/M, Minix, OS/2,
and numerous other systems support a generalized fseek.  Even VAX/VMS,
which is heavily into record-based I/O, supports stream-LF files that
allow the original fseek semantics to be preserved.  There is no
reason, other than the practical realization that it's more profitable
to channel resources into persuading ANSI than into changing the
operating system, that other vendors cannot do the same thing.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi