[BUG] fseek behavior differs on whence parameter

[BUG] fseek behavior differs on whence parameter

[Mathias Lang]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1859 bytes --]

Re: [BUG] fseek behavior differs on whence parameter

[Rich Felker]

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

Re: [BUG] fseek behavior differs on whence parameter

[Rich Felker]

On Wed, Oct 23, 2019 at 07:45:13AM -0400, Rich Felker wrote:
> 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.

On further thought, while I still don't think this is a conformance
distinction, I think supporting SEEK_DATA for fseek[o] is a
bug/mistake. Semantically it should seek over holes relative to the
logical file position, but without special work in stdio layer to
support it, it will seek over holes relative to the underlying fd
position after buffering. This will cause loss of data already in the
buffer.

As such, although for different reasons, I think I'm in support of the
change you requested. What do you think?

Rich