gwyn@smoke.brl.mil (Doug Gwyn) (06/27/90)
From: Doug Gwyn <gwyn@smoke.brl.mil> In article <735@longway.TIC.COM> From: Paul Rabin <rabin@osf.org> >Section 6.5.3.4 specifies that lseek() returns EINVAL if the resulting >file offset would be invalid, but it doesn't say which file offsets >are invalid. That's right; it would be overspecification to try to spell out which file offsets are required to be valid. > An illegal file offset that would cause [EINVAL] to be > returned may be both implementation defined and device > dependent (for example, memory may have few illegal values). > A negative file offset may be legal for some devices in > some implementations. The rationale is also right. >The standard does not specify an error for I/O operations attempted at >an illegal offset. It _seems_ that the intent is for an offset to be legal >only if some I/O operation is possible at that offset, and for it to be >impossible to set an illegal offset. This is not changed in the 1990 >revision of the standard or in the P1003.1b supplement. I/O even at a valid offset may nonetheless fail, depending on the type of file and on various circumstances. It is certainly the intent of a successful lseek() that under appropriate circumstances a subsequent I/O operation MIGHT succeed, but it is not required. (Consider lseek() to the end of a non-extendable file.) >Some implementations do permit lseek() to set "illegal" file offsets, >and some applications take advantage of this. Does anyone know whether >the original members of the 1003.1 working group intended to permit this? If lseek() reports failure, the attempted offset should not stick. Otherwise, it should. The absolute offset may be negative and succeed for some file types; this was intentional. For example, on a process opened as a file a negative offset may be useful to access registers and the u-area. >Does anyone have an implementation that returns [EINVAL] if the >file offset resulting from lseek() is negative, or positive and "too >large"? Are file offsets represented in your kernel by a signed or an >unsigned type? On 4.3BSD, lseek() to a negative absolute offset on an ordinary file reports success and returns the (negative) absolute offset. This is probably a bug rather than a feature, since I'm sure no valid data can be returned from the negative bytes of an ordinary file. Volume-Number: Volume 20, Number 52