From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 6353124811 for ; Sun, 2 Jun 2024 05:01:25 +0200 (CEST) Received: (qmail 7257 invoked by uid 550); 2 Jun 2024 03:01:19 -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 7222 invoked from network); 2 Jun 2024 03:01:18 -0000 Date: Sun, 2 Jun 2024 05:01:10 +0200 From: Ismael Luceno To: Rich Felker Cc: musl@lists.openwall.com Message-ID: References: <20240601010328.27409-1-ismael@iodev.co.uk> <20240601023429.GJ10433@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240601023429.GJ10433@brightrain.aerifal.cx> Subject: Re: [musl] [PATCH] ioctl: Fix implicit constant conversion overflow On 31/May/2024 22:34, Rich Felker wrote: <...> > > +#define _IOW(a,b,c) _IOC(_IOC_WRITE,(a),(b),(int)sizeof(c)) > > +#define _IOR(a,b,c) _IOC(_IOC_READ,(a),(b),(int)sizeof(c)) > > +#define _IOWR(a,b,c) _IOC(_IOC_READ|_IOC_WRITE,(a),(b),(int)sizeof(c)) > > I don't see how this helps with the warning you're trying to suppress, GCC disagrees; the warnings go away because it's this element that causes the whole expression to be promoted to unsigned long long, so making it smaller (we can use unsigned int instead) avoids the issue. > since _IOC_{READ,WRITE} already have unsigned type. If you changed > that, you would then have *real overflows* (undefined behavior) > instead of the well-defined, valid implicit conversions -Werror is > complaining about. This expresssion is supposed to fit 32-bit anyway, isn't it?