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 4e856473 for ; Mon, 20 Jan 2020 12:09:44 +0000 (UTC) Received: (qmail 24476 invoked by uid 550); 20 Jan 2020 12:09:43 -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 24458 invoked from network); 20 Jan 2020 12:09:42 -0000 Date: Mon, 20 Jan 2020 13:09:30 +0100 From: Szabolcs Nagy To: Olaf Meeuwissen Cc: musl@lists.openwall.com Message-ID: <20200120120930.GO23985@port70.net> Mail-Followup-To: Olaf Meeuwissen , musl@lists.openwall.com References: <8736cajtt1.fsf@member.fsf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <8736cajtt1.fsf@member.fsf.org> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [musl] [BUG] ioctl: overflow in implicit constant conversion * Olaf Meeuwissen [2020-01-20 19:39:22 +0900]: > Hi all, >=20 > I've been asked[1] to upstream an issue I initially submitted[2] to the > Alpinelinux project. >=20 > [1]: https://gitlab.alpinelinux.org/alpine/aports/issues/7580#note_63663 > [2]: https://gitlab.alpinelinux.org/alpine/aports/issues/7580 >=20 > You can find all the details in that issue[2], but to save you the trip, > here's the gist of it. >=20 > I get `overflow in implicit constant conversion` compiler warnings on > some `ioctl()` calls in my code. the overflow warning is valid, but harmless. > I found >=20 > ``` c > int ioctl (int, int, ...) > ``` >=20 > in `/usr/include/sys/ioctl.h` and the following in > `/usr/include/bits/ioctl.h` (included by the former) >=20 > ``` c > #define _IOC(a,b,c,d) ( ((a)<<30) | ((b)<<8) | (c) | ((d)<<16) ) > #define _IOC_NONE 0U > #define _IOC_WRITE 1U > #define _IOC_READ 2U >=20 > #define _IO(a,b) _IOC(_IOC_NONE,(a),(b),0) > #define _IOW(a,b,c) _IOC(_IOC_WRITE,(a),(b),sizeof(c)) > #define _IOR(a,b,c) _IOC(_IOC_READ,(a),(b),sizeof(c)) > #define _IOWR(a,b,c) _IOC(_IOC_READ|_IOC_WRITE,(a),(b),sizeof(c)) > ``` >=20 > If I am not mistaken and assuming a 32-bit int, that means that any > second argument passed to `ioctl()` that is created using the `_IOR` > or `_IOWR` macros will be an *unsigned* 32-bit integer with its most > significant bit set and will trigger the warning I observe. >=20 > BTW, most other distributions I compile on define ioctl() as >=20 > ``` c > int ioctl (int, unsigned long, ...) > ``` 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. changing the type is an api and abi break in musl. we could try to silence the warning instead (e.g via explicit cast in _IOC or in an ioctl macro). >=20 > and chaging your declaration to take an `unsigned int` =E2=80=9Cfixes= =E2=80=9D this > for me. >=20 > This happens when I compile with `-Wall -pedantic` on x86_64/amd64. > When compiling without `-pedantic` the warning goes away. >=20 > Since my initial report (against musl-1.1.16) the warning has changed to > something like >=20 > overflow in conversion from 'long unsigned int' to 'int' changes value > from '3221771554' to '-1073195742' [-Woverflow] >=20 > and I have not checked what happens when `-pedantic` is not given. Nor > have I checked whether my `unsigned int` still =E2=80=9Cfixes=E2=80=9D th= is. >=20 > I still see this with 1.1.24. >=20 > I think this is a bug and would like to see this fixed. it is worth fixing if the fix does not cause bigger problems than the warning we are fixing.