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 1A3793889E0D for ; Mon, 14 Nov 2022 18:14:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1A3793889E0D 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 3E6C916004A; Mon, 14 Nov 2022 10:14:09 -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 RsymnVl8eV9i; Mon, 14 Nov 2022 10:14:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6C58C160091; Mon, 14 Nov 2022 10:14:08 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 6C58C160091 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1668449648; bh=dXuscNRyaXvskVV3TKclIsX4cu+nDAFlRKgOcaqXNoc=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=XrynBVxJ6cjirHj0DVOJk2odRcfjuRy9OlmTKp/eKx/s1lVUGBeQ+hy/ju/wnAHGH qUoaAycNeuTsTXE8CZ8KEuRkw8sNWBnILGBZ0wmCES+LMHmcfyfAxYaaxel27yDuun hwuRto4IxCQmLLt6zoD2WM6v8DKmldzErXliViSE= 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 k6aN5jiP05fF; Mon, 14 Nov 2022 10:14:08 -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 2D4D116004A; Mon, 14 Nov 2022 10:14:08 -0800 (PST) Message-ID: Date: Mon, 14 Nov 2022 10:14:07 -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: Aaron Ballman Cc: Zack Weinberg , 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> 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.3 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-14 04:41, Aaron Ballman wrote: > it's generally a problem when autoconf relies on invalid > language constructs Autoconf *must* rely on invalid language constructs, if only to test whether the language constructs work. And Clang therefore must be careful about how it diagnoses invalid constructs. Clang shouldn't willy-nilly change the way it reports invalid constructs, as that can break Autoconf. > issues of security > like statically known instances of UB It's fine to report those; I'm not saying don't report them. All I'm saying is that Clang should be careful about *how* it reports them. At the very least if there are going to be changes in this area, the Clang developers should notify Autoconf (and presumably other) downstream users of the changes, and provide a supported way to get the old behavior for reporting, and give downstream time to adapt.