kenny@uiucdcsb.cs.uiuc.edu (09/13/87)
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.peter@sugar.UUCP (09/16/87)
> Yet I don't see anything in the standard forbidding forward read after > write. In the general case (other than tapes) reading after a write is perfectly acceptable. For tapes you can: disallow open in r+ or w+ mode (as you suggest) or, set end of file after every write, so the read will read 0 bytes. The latter is probably better. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` ^^^^^^^^^^^^^^ Not seismo!soma (blush)
gwyn@brl-smoke.ARPA (Doug Gwyn ) (09/21/87)
In article <165600012@uiucdcsb> kenny@uiucdcsb.cs.uiuc.edu writes: >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? The following is NOT an official X3J11 response: Magtapes have always been problematic for simple file models. (Consider that some interfaces do not support writing records containing an odd number of bytes, and that one cannot in general write on a magtape file unless there are no files following it.) If an implementation cannot support the "+" modes in a reasonable manner (block-replaceable magtape a la DECtape), then it really ought to return an error indication when an attempt is made to open a magtape device in such a mode. Alternatively, it could defer the error indication until the I/O operation that won't work right is attempted, although this is much less desirable. I know that it is hard to construct such an implementation on some operating systems (including many UNIX variants), but there really isn't much that can be done about this at the C standardization level. Not all magtape implementations allow convenient access to positioning operations. In particular, some older UNIX magtape drivers did not support such operations (other than rewind, and occasionally file-skip on close).