From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) by sourceware.org (Postfix) with ESMTPS id EF73C3853D48 for ; Thu, 17 Nov 2022 18:45:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EF73C3853D48 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu 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 X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,JMQ_SPF_NEUTRAL,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,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 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.