From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14858 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [BUG] fseek behavior differs on whence parameter Date: Wed, 23 Oct 2019 07:45:13 -0400 Message-ID: <20191023114513.GN16318@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="169263"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: musl@lists.openwall.com To: Mathias Lang Original-X-From: musl-return-14874-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 23 13:45:31 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iNF50-000hwG-L0 for gllmg-musl@m.gmane.org; Wed, 23 Oct 2019 13:45:30 +0200 Original-Received: (qmail 28005 invoked by uid 550); 23 Oct 2019 11:45:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 27987 invoked from network); 23 Oct 2019 11:45:27 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14858 Archived-At: 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