From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cventin.lip.ens-lyon.fr (cventin.lip.ens-lyon.fr [140.77.13.17]) by sourceware.org (Postfix) with ESMTPS id 8F77E3858D32 for ; Fri, 31 Mar 2023 15:31:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8F77E3858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vinc17.net Authentication-Results: sourceware.org; spf=none smtp.mailfrom=vinc17.net Received: from vlefevre by cventin.lip.ens-lyon.fr with local (Exim 4.96) (envelope-from ) id 1piGjA-00FKZ4-16; Fri, 31 Mar 2023 17:31:44 +0200 Date: Fri, 31 Mar 2023 17:31:44 +0200 From: Vincent Lefevre To: libc-alpha@sourceware.org Subject: Re: Bad interaction between signal constants and -Wsign-conversion Message-ID: <20230331153144.GB2458@cventin.lip.ens-lyon.fr> Mail-Followup-To: Vincent Lefevre , libc-alpha@sourceware.org References: <280b4afe-d080-4be5-a296-ec914b0b5439@app.fastmail.com> <4e573abd-9ba0-e483-ab48-84e9ea98f90a@gmail.com> <20230330135911.GA2458@cventin.lip.ens-lyon.fr> <9d23a09f-31d6-17ce-5bd1-37f7035d1371@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9d23a09f-31d6-17ce-5bd1-37f7035d1371@gmail.com> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/2.2.10+60 (d2ed5d18) vl-149028 (2023-03-25) X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2023-03-30 16:09:12 +0200, Alejandro Colomar wrote: > On 3/30/23 15:59, Vincent Lefevre wrote: > > But concerning struct sigaction in particular, shouldn't this be fixed > > in POSIX? > > IMHO, POSIX, and in general, standards, should follow implementations > rather than lead them. I think changes should start as vendor > extensions. However, there could be a discussion concerning POSIX at the same time. > For example, timespec::tv_nsec was mandated to be long by POSIX and > C11, but glibc used 'long long' in some cases, because it was > necessary. I would say using 'unsigned int' here would be a nice GNU > extension, and if it proves its value, POSIX could later pick it. > > However, as Zack said, I'm not sure how we could check if any programs > out there are using this member unreasonably. But on the opposite, it is possible that some programs assume that flags are positive and these programs have not been tested with a negative flag. So they could already be buggy, and an unsigned int could fix them. BTW, some systems seem to have an unsigned sa_flags: https://github.com/github/git-msysgit/blob/master/compat/mingw.h https://www.google.com/search?q=%22unsigned+long+sa_flags%22 https://www.google.com/search?q=%22unsigned+int+sa_flags%22 -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)