mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Mathias Lang <mathias.lang@bpfkorea.org>
Cc: musl@lists.openwall.com
Subject: Re: [BUG] fseek behavior differs on whence parameter
Date: Thu, 24 Oct 2019 10:06:49 -0400	[thread overview]
Message-ID: <20191024140649.GO16318@brightrain.aerifal.cx> (raw)
In-Reply-To: <20191023114513.GN16318@brightrain.aerifal.cx>

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


      reply	other threads:[~2019-10-24 14:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-23  5:48 Mathias Lang
2019-10-23 11:45 ` Rich Felker
2019-10-24 14:06   ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191024140649.GO16318@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=mathias.lang@bpfkorea.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).