[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200120171425.GL30412@brightrain.aerifal.cx>
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.
