Re: [BUG] fseek behavior differs on whence parameter

[Rich Felker <dalias@libc.org>]

On Wed, Oct 23, 2019 at 02:48:21PM +0900, Mathias Lang wrote:
> Hi everyone,
> As part of my recent effort to get the D Programming Language (
> https://dlang.org/) to work on Alpine Linux, I've hit what I believe is a
> bug in Musl.
> Dlang relies heavily on libc, and obviously is historically glibc-based on
> POSIX.
> 
> When porting to Alpine/Musl, one of the unittests that failed is calling
> `fseek` with the value '3' for whence. The call is expected to fail, and it
> does on Glibc, but succeed on Musl.
> The reason for this difference is that Musl just forwards its whence
> argument to the lseek syscall, which accepts '3' (aka SEEK_DATA) as a
> parameter.
> 
> However, glibc explicitly checks for if the value is one of SEEK_SET,
> SEEK_END, SEEK_CUR (
> https://github.com/lattera/glibc/blob/895ef79e04a953cac1493863bcae29ad85657ee1/libio/ioseekoff.c#L32-L38),
> and POSIX defines the function as setting errno to EINVAL if the "whence
> argument is invalid" (
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/fseek.html). The
> only man page I could find that mentions 'SEEK_{DATA,HOLE}' is `lseek`'s.
> 
> In light of this, it looks to me like Musl behavior is the one that should
> be changed.
> 
> For reference, original discussions:
> - https://github.com/alpinelinux/aports/pull/11931#issuecomment-544831142
> - https://github.com/dlang/phobos/pull/7244#issuecomment-545256706
> 
> 
> P.S: I am not subscribed to the ML, please CC me.

Generally, I think the condition "is invalid" is to be interpreted
differently from "is not one of the values [X], [Y], or [Z]". For
example, see the resolution to Austin Group issue #1187, where the
text was previously "contains flags other than SS_DISABLE" and was
changed to "has SS_ONSTACK or invalid flags" specifically for the sake
of allowing extensions (it's the stated intent in the fix):

http://austingroupbugs.net/view.php?id=1187

I believe there are a few other places where this pattern can be seen
but I don't know them right off. One might object that the "shall
fail" becomes meaningless then, since the implementation could just
define (document) all other possible values as nops. Indeed this is a
possibility, but then future versions of the implementation would have
to break compatibility with documented behavior of past versions of
themselves to make use of the value as extensions, which seems like a
decent deterrent.

Aside from strict conformance (which may be a valid reason if your
interpretation is correct, but I tend to think it's not based on the
above), the property this test is asserting has no value. An invalid
value of the whence argument cannot arise except as a result of a
programming error (as opposed to useful errors that arise as a result
of exceptional or even regular runtime conditions). Either the
argument is a literal (typical), or it's selected from one of the
standard values (or a known-supported extension) via some sort of
mapping/table; there is no meaningful, non-erroneous way to plug
arbitrary integers into it.

Rich