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 379C938A90B7 for ; Tue, 15 Nov 2022 19:08:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 379C938A90B7 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 4E365160045; Tue, 15 Nov 2022 11:08:04 -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 cXXCvFKP3HpR; Tue, 15 Nov 2022 11:08:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 882B0160091; Tue, 15 Nov 2022 11:08:03 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 882B0160091 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1668539283; bh=++y9fHfTpxeUuNHh1BUY6xFW5k//FL2Hxd52pYNL088=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=F/o9IXU39djJEJuVho75569bTgFzT7AvPvlwF3Ycna3HaSu1pUhqfWmu0xansVPD/ htwOKd0MMOkLhinzUKSN4tkPilHOB0zPdUwusV60uzmf9rGNpWA5L+yBZvMZT4GOT6 vXv80oLcDs2wf/kkUCHHqBXWlxELN6mm4aslh+80= 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 kS6JUbxk_IKw; Tue, 15 Nov 2022 11:08:03 -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 4BAC2160045; Tue, 15 Nov 2022 11:08:03 -0800 (PST) Message-ID: <9cb106e9-16ff-65ec-6a44-6567c77521dc@cs.ucla.edu> Date: Tue, 15 Nov 2022 11:08:03 -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: Jonathan Wakely Cc: Aaron Ballman , 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-15 06:50, Jonathan Wakely wrote: > Could you clarify what you mean, with a concrete example? Surely as > long as errors are reported on stderr and the compiler exits with > non-zero status, that's an acceptable way to report errors? Not if the "error" is harmless as far as Autoconf is concerned, which is what led to this thread. The concrete example here is that Autoconf needs to check whether a function can be linked to (as opposed to checking the function's signature). Clang shouldn't get in the way. In lots of places the C standard says behavior is undefined, even though the behavior is fine on the current platform for the intended use. It's not just the example we're talking about; adding zero to a null pointer is another such example. In such cases it's OK for Clang to warn, but having Clang exit with nonzero status is overkill and counterproductive.