[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.20.13.1708301511090.21360@monopod.intra.ispras.ru>
Date: Wed, 30 Aug 2017 15:55:17 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: RTC_RD_TIME
On Tue, 29 Aug 2017, Rich Felker wrote:
> I don't know any good fix. The problem is that the glibc (and others')
> ioctl function has a signature mismatching the standard one, with an
> unsigned argument instead of signed, and the macro values are outside
> the range of signed int. Fortunately the warning is harmless but
> obviously it can impact builds with -Werror or policy about warnings..
Type confusion causes musl to wrongly pass sign-extended value to the
kernel (instead of zero-extended). That's a real issue, and it's a bit
disappointing you have not mentioned it.
(BSD flavours as well as Linux have 'unsigned long' there, so I don't
understand why it was ok for POSIX to document request type as 'int';
wouldn't it be appropriate for musl to just follow existing practice
here rather than the letter of the standard?)
Without changing the prototype, I think a possible fix is
#ifdef __GNUC__
#define ioctl(fd, req, ...) ioctl(fd, (int)(req), ##__VA_ARGS__)
#endif
(plus a fix in ioctl.c for the sign extension issue)
although I don't understand how the quoted warning appears; I can
produce another one with -Wsign-conversion, but not this.
Alexander
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.
