From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13265 invoked from network); 22 Feb 2023 15:54:09 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 22 Feb 2023 15:54:09 -0000 Received: (qmail 28251 invoked by uid 550); 22 Feb 2023 15:54:04 -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 28205 invoked from network); 22 Feb 2023 15:54:03 -0000 Date: Wed, 22 Feb 2023 10:53:49 -0500 From: Rich Felker To: Markus Wichmann Cc: musl@lists.openwall.com Message-ID: <20230222155349.GC4163@brightrain.aerifal.cx> References: <99826a90-6658-099e-9df8-d0bba78b8f0f@gmail.com> <20230221160455.GF1903@voyager> <20230222031730.GB4163@brightrain.aerifal.cx> <20230222042244.GH1903@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230222042244.GH1903@voyager> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: [BUG] ioctl: overflow in implicit constant conversion On Wed, Feb 22, 2023 at 05:23:12AM +0100, Markus Wichmann wrote: > On Tue, Feb 21, 2023 at 10:17:31PM -0500, Rich Felker wrote: > > 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. > > > > Yeah, sorry, I had missed that the directions are defined as unsigned > constants. That turns any shift that might have been undefined into an > unsigned shift, where it is defined. As I said in the other mail, the > compiler is just warning about nothing here, and it should probably not > warn for system header files, anyway. > > We may be able to silence the compiler by adding an explicit int > conversion to the _IOC macro. But I'm not sure if we want to set a > precedent that we will add code just to shut up overeager warnings. I think it's reasonably arguable that the ioctl command macros should have the right type matching the type the ioctl function takes. But it's possible there could be places where sign extension bites you then. As a stupid example, if someone bypassed the libc function and tried to make the ioctl syscall directly, having the macros be of signed type would cause the kernel to receive them with a bunch of ones in the high bits, and possibly reject them as a result. I'm not sure if there's any reasonable usage that would be impacted, though. Rich