Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!iuvax!pur-ee!uiucdcs!uiucdcsb!kenny
From: kenny@uiucdcsb.cs.uiuc.edu
Newsgroups: comp.lang.c
Subject: Yet another fseek() question
Message-ID: <165600012@uiucdcsb>
Date: Sun, 13-Sep-87 15:28:00 EDT
Article-I.D.: uiucdcsb.165600012
Posted: Sun Sep 13 15:28:00 1987
Date-Received: Tue, 15-Sep-87 03:56:19 EDT
Lines: 20
Nf-ID: #N:uiucdcsb:165600012:000:857
Nf-From: uiucdcsb.cs.uiuc.edu!kenny    Sep 13 14:28:00 1987


At the risk of beating a dead horse, I've a question about fseek() to
those with an ear to the standards committee.

Fseek() as described for TEXT files can be made to work even on
magnetic tapes with comparatively little effort, except for one minor
problem:  tapes cannot reliably read data beyind the last data
written.

Yet I don't see anything in the standard forbidding forward read after
write.  Did the implementors not consider tape I/O, figure that an
implementation can just disallow "r+" and "w+" modes for tapes,
consider tapes to be non-seekable files (but they CAN forward-space,
backspace, and rewind), or have I overlooked something?

Kevin Kenny	{ihnp4,pur-ee,convex}!uiucdcs!kenny
		kenny@b.cs.uiuc.edu

PS: Otherwise the committee did it RIGHT.  I've no arguments with the
semantics of fseek() on text files other than this minor point.