Date: Mon, 20 Jan 2020 12:14:25 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: [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
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.