[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230222031730.GB4163@brightrain.aerifal.cx>
Date: Tue, 21 Feb 2023 22:17:31 -0500
From: Rich Felker <dalias@...c.org>
To: Markus Wichmann <nullplan@....net>
Cc: musl@...ts.openwall.com
Subject: Re: Re: [BUG] ioctl: overflow in implicit constant conversion
On Tue, Feb 21, 2023 at 05:04:55PM +0100, Markus Wichmann wrote:
> On Mon, Feb 20, 2023 at 09:26:05PM -0800, Ralph Little wrote:
> > Hi,
> > I have been picking up some old pending issues related to the SANE project.
> > One of our CI builds is on Alpine and it is generating warnings for ioctl()
> > calls from the musl library:
> >
> > |error: overflow in conversion from 'long unsigned int' to 'int' changes
> > value from '2147577985' to '-2147389311' [-Werror=overflow]
> > |
> > ||ioctl (fd, PPRSTATUS, &status);
> >
> > ||I see that Olaf Meeuwissen raised this issue a couple of years ago and the
> > discussion petered out somewhat and I don't believe that the issue was ever
> > really resolved:
> >
> > https://www.openwall.com/lists/musl/2020/01/20/2
> >
> > Is there any possibility that this could be addressed in the near future?
> > I see that Alpine have closed their issue and are not interested in patching
> > their downstream musl:
> >
> > https://gitlab.alpinelinux.org/alpine/aports/-/issues/7580#note_287168
> >
> > Cheers,
> > Ralph Little
> >
> >
> >
> >
> >
>
> So, I had a look at it. As far as I can tell, the issue is that musl
> declares ioctl()'s second argument to be an int. Together with the other
> defintions, this means that any _IOC_READ constant will overflow and
> generate those warnings. Also, this is technically undefined behavior,
> as value bits are shifted into the sign bit of a signed integer.
Unless you're seeing something I'm not, there's no UB. The shifts take
place on the unsigned type, and the conversion from unsigned to signed
is implementation-defined, not undefined. The implementation-defined
definition relevant to us is modular reduction.
I'm not sure if there's anything reasonable that can be done here on
our side to be more friendly while still conformant, but getting rid
of -Werror=overflow (which is treating well-defined code as an error)
will solve the problem.
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.
