From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 47e6c5e3 for ; Mon, 20 Jan 2020 17:14:41 +0000 (UTC) Received: (qmail 13740 invoked by uid 550); 20 Jan 2020 17:14:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 13722 invoked from network); 20 Jan 2020 17:14:37 -0000 Date: Mon, 20 Jan 2020 12:14:25 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200120171425.GL30412@brightrain.aerifal.cx> References: <8736cajtt1.fsf@member.fsf.org> <20200120120930.GO23985@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] [BUG] ioctl: overflow in implicit constant conversion On Mon, Jan 20, 2020 at 03:57:33PM +0300, Alexander Monakov wrote: > I'll reiterate points raised previously in https://www.openwall.com/lists/musl/2017/08/30/10 > > On Mon, 20 Jan 2020, Szabolcs Nagy wrote: > > > this is a conformance bug, since posix specifies int. > > > > one could argue that linux requires unsigned long, but > > the correct way to introduce linux specific apis is to > > give them a different name, not something that clashes > > with standard names that have specified semantics. > > But _why_ does POSIX specify 'int' there? Checking on freebsd.org > man pages I see that all BSD flavours had 'unsigned long' and Linux > followed that. Did POSIX fail to document prevailing practice in > this case? I'm not sure. I'm guessing there were more influential proprietary unices at the time whose definitions won out in committee. After all, the POSIX ioctl definition was built around STREAMS, not other historic use which seems to have been deemed sufficiently system-specific not to standardize despite having widespread overlapping parts. :( But in any case, portable software already has to be tolerant of either version. > I still think the warning points to a bigger problem that with > musl the kernel receives a sign-extended value. If this is actually an issue it can be fixed with: - int r = __syscall(SYS_ioctl, fd, req, arg); + int r = __syscall(SYS_ioctl, fd, (unsigned)req, arg); It has no relation to the public interface of the function. Rich