🚀 go-pugleaf

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