[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 24 Oct 2019 10:06:49 -0400
From: Rich Felker <dalias@...c.org>
To: Mathias Lang <mathias.lang@...korea.org>
Cc: musl@...ts.openwall.com
Subject: Re: [BUG] fseek behavior differs on whence parameter
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
