From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 061B71F55B for ; Thu, 21 May 2020 20:59:21 +0000 (UTC) Received: from localhost ([::1]:45030 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbsHf-0006yM-QV for normalperson@yhbt.net; Thu, 21 May 2020 16:59:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48884) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbsHc-0006yE-M4 for bug-gnulib@gnu.org; Thu, 21 May 2020 16:59:16 -0400 Received: from mo6-p00-ob.smtp.rzone.de ([2a01:238:20a:202:5300::10]:25907) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbsHa-0003Ez-JW for bug-gnulib@gnu.org; Thu, 21 May 2020 16:59:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1590094750; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=TXUlxh6CS7nQQ0W5ZVfA0vsLDPGmYAbiHr7o8tA2BhM=; b=IQxmLfhaDnONXoEuArY8IX5faBoWO4ZNDSADEON1FcLX92FdY6HMoCREq3+jDYnM/t tHbIMMpFEZBRm1UP45YYuxA0vxAvJFX+SbvKqypaA/+swqFaFoz000VWoZrGZqOM/xv5 wjZ0joCB+DQCevvEVEe8KsZNIGJRfyKJ4wPYqsGs57KfNpkcSs1bcZf2TmL6iKx2GhoY iuMR8nLAVdJ9IHRGzGAsjptZXfNbBpQJ+tRfrnKF8EwUpEz507oQxO8XXkxBGkzzxw3I 3jmtns2fZCjlWAbEFJO3xd3QP3oFJjowDY9VX5fqdIsMlYjdm352Jtsh5F8nlgWGSNWR eWlg== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOH6fzxfs=" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 46.7.0 DYNA|AUTH) with ESMTPSA id x0bd30w4LKx9Enf (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Thu, 21 May 2020 22:59:09 +0200 (CEST) From: Bruno Haible To: Paul Eggert Subject: Re: SA_RESETHAND Date: Thu, 21 May 2020 22:59:08 +0200 Message-ID: <1722583.VNo0odqiRZ@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-177-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <025096be-d6f6-8017-7473-7f1e75588a64@cs.ucla.edu> References: <1914708.U9Lh6kAjoy@omega> <025096be-d6f6-8017-7473-7f1e75588a64@cs.ucla.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=2a01:238:20a:202:5300::10; envelope-from=bruno@clisp.org; helo=mo6-p00-ob.smtp.rzone.de X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tim =?ISO-8859-1?Q?R=FChsen?= , bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Paul Eggert wrote: > > - Should glibc define SA_RESETHAND as ((int)0x80000000) ? > > Then SA_RESETHAND could not be used in preprocessor directives any more. > > POSIX would allow that, as it doesn't require SA_RESETHAND to be usable > in preprocessor directives. However, too much software uses it that way > anyway (e.g., squid/src/tools.cc has "#if SA_RESETHAND == 0 && > !_SQUID_WINDOWS_"). So I have my doubts whether this change would be > adopted. > > > - Should clang be silent about this case of implicit conversion? > > That would solve the problem, although the people who want lots of > warnings might want one here too. > > > - Should we discourage users from using -fsanitize=implicit-integer-sign-change? > > For me that flag tends to cause more problem than it cures. So we could > tell people that Gnulib won't worry about that warning. Thanks for your evaluation. I think this should best be fixed by clang, and therefore have registered a clang bug: https://bugs.llvm.org/show_bug.cgi?id=46025 Bruno