a couple of random questions
kenny at uiucdcsb.cs.uiuc.edu
kenny at uiucdcsb.cs.uiuc.edu
Sat Apr 16 05:52:00 AEST 1988
Subject: Re: a couple of random questions
/* Written 10:05 am Apr 14, 1988 by davidsen at steinmetz.ge.com in uiucdcsb:comp.lang.c */
/* ---------- "Re: a couple of random questions" ---------- */
In article <530 at vsi.UUCP> friedl at 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
More information about the Comp.lang.c
mailing list