Path: utzoo!utgpu!water!watmath!clyde!att-cb!osu-cis!tut.cis.ohio-state.edu!rutgers!iuvax!pur-ee!uiucdcs!uiucdcsb!kenny
From: kenny@uiucdcsb.cs.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: a couple of random questions
Message-ID: <165600037@uiucdcsb>
Date: 15 Apr 88 19:52:00 GMT
References: <530@vsi.UUCP>
Lines: 46
Nf-ID: #R:vsi.UUCP:530:uiucdcsb:165600037:000:1983
Nf-From: uiucdcsb.cs.uiuc.edu!kenny    Apr 15 13:52:00 1988


Subject: Re: a couple of random questions
/* Written 10:05 am  Apr 14, 1988 by davidsen@steinmetz.ge.com in uiucdcsb:comp.lang.c */
/* ---------- "Re: a couple of random questions" ---------- */
In article <530@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes:
|      Second, what is the portable way to rewind a Unix file
| descriptor?  On almost every machine I have ever used:
| 
|         lseek(fd, (off_t)0, SEEK_SET);
| 

Any implementation which doesn't use 
	lseek(int, long, int)
In the K&R manner (pg 164) will break virtually every program which uses
the feature. I have to check dpANS on this, or someone can post and tell
me that they found some way to justify doing something else.
/* End of text from uiucdcsb:comp.lang.c */

dpANS doesn't *have* lseek, since it's a low-level routine, but rather
has fseek; it also has ftell.

On *binary* files, you can fseek to anywhere.

On *text* files, the only things you can do portably are:
	fseek (stream, 0L, SEEK_SET); /* Rewind */
	fseek (stream, 0L, SEEK_CUR); /* Do nothing */
	fseek (stream, 0L, SEEK_END); /* Position to end of file */
	fseek (stream, p, SEEK_SET);  /* Position to previous location */

In the last form, the seek pointer p must be a long returned from an
earlier call to ftell.

While the standard doesn't mention this explicitly, I would not be
upset to see an implementation disallow attempts to seek beyond the
end of the last write() to a text file; in other words, if you rewrite
stuff in the middle of a text file, anything beyond the point of the
rewrite *may* be lost.  This restriction is essential to handle media
whose nature forbids `forward read after write' operations.  Moreover,
I wouldn't be distressed to see a restriction forbidding read()
operations which extend beyond the end of the last write().

Doug, did you ever submit the change request on the consideration that
I outlined in the last paragraph?  I know we discussed this, but I
don't remember the conclusion.

Kevin