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-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2, SPF_HELO_PASS,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 1C1621F910 for ; Thu, 17 Nov 2022 18:46:21 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=cs.ucla.edu header.i=@cs.ucla.edu header.b="A2qvn7e8"; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ovjti-0002cf-PY; Thu, 17 Nov 2022 13:46:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ovjth-0002cD-NM; Thu, 17 Nov 2022 13:46:01 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ovjtf-0004OM-E7; Thu, 17 Nov 2022 13:46:01 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D934C160037; Thu, 17 Nov 2022 10:45:55 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 1VJtv4p9LB1t; Thu, 17 Nov 2022 10:45:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 982E1160054; Thu, 17 Nov 2022 10:45:54 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 982E1160054 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1668710754; bh=2DgKFDccgg7hHz3byn4v0oZz6FEkyaE1N4BITqw0HgE=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=A2qvn7e8cavLYZ404/0xs7fMvd5OMVk+0iS5x692sZV1WtIXwuhOFc382QAKBnjjI PXJrglhnaVbcHZkmhhJ4j0iCOMlT9XJA54FJEQHgw/MDO+mPnjMTH+Ti4f5UNERaTm WyVZ9jI/AOGT1RaubWOfnaR1aPovF97LmY1i7KdM= X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ECPTID47th2H; Thu, 17 Nov 2022 10:45:54 -0800 (PST) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 60EAD160037; Thu, 17 Nov 2022 10:45:54 -0800 (PST) Message-ID: Date: Thu, 17 Nov 2022 10:45:53 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US To: noloader@gmail.com Cc: c-std-porting@lists.linux.dev, autoconf@gnu.org, gcc@gcc.gnu.org, cfe-commits@lists.llvm.org, Gnulib bugs References: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> <251923e7-57be-1611-be10-49c3067adf0d@cs.ucla.edu> <7ef0ce03-d908-649a-a6ee-89fea374d2b1@cs.ucla.edu> <9cb106e9-16ff-65ec-6a44-6567c77521dc@cs.ucla.edu> <06a5d2cd-44eb-7404-17f3-ff64dd505427@cs.ucla.edu> <4cfa16b3-e9e0-0ec0-659c-e4aef6090995@cs.ucla.edu> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: How can Autoconf help with the transition to stricter compilation defaults? In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org On 2022-11-16 10:40, Jeffrey Walton wrote: > This line of arguments is not persuasive. It is full of logical fallacies. ... none of which you stated. No matter how we solve the problem, it will be a hack that exploits "logical fallacies" (whatever that means). However, a reaction "You violated the C standard! You deserve to be punished!" is not the best one for the overall software ecosystem. Lots of programs violate the C standard every day, and Clang supports them anyway. Yesterday I dealt with this Autoconf bug report: https://lists.gnu.org/r/autoconf/2022-11/msg00092.html which basically said, "Here's some longstanding buggy code that uses Autoconf. This buggy code happened to work in the previous stable Autoconf version, but it stopped working in the bleeding-edge version." Did I respond, "That's buggy code and it deserves to be punished?" No, I responded that it's buggy code that needs to be fixed (and gave a fix), but fixing this sort of thing is a hassle for distributors and so I also installed a minor hack to bleeding-edge Autoconf that lets the buggy code work again, at least for now. It would help if Clang developers could cooperate to address this potential problem with stricter compilation defaults. It's a real problem. And it shouldn't require much work on the Clang side to address it.