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 ACF4D3947415 for ; Tue, 15 Nov 2022 23:09:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ACF4D3947415 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 F040116004F; Tue, 15 Nov 2022 15:09:20 -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 V2yyU0lyiPV9; Tue, 15 Nov 2022 15:09:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 199F7160091; Tue, 15 Nov 2022 15:09:20 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 199F7160091 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1668553760; bh=mGbiPLEgPjyz0kIccMyM8siGwhJhxtEhCc8EZY8vIOI=; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type: Content-Transfer-Encoding; b=gsBg+9ypX/Jgl+5y69duMx7edPaaXu9P+N0oOy1rYLD3u9ZtG3e5FrW1TGniC9YtS qJDG5n6NI1/q0coS8xpZNP65vFB5Arkq068EezDYxdyfdMY19lQIH9E4WcmeG7dy1e EWOAwyAfs6EBpzKYFCKne9/DhIXr0fPJ7Eu2SrxU= 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 Os0M5ZOtawjh; Tue, 15 Nov 2022 15:09:20 -0800 (PST) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id E62E316004F; Tue, 15 Nov 2022 15:09:19 -0800 (PST) Message-ID: <7ee13f9a-f3e9-8b0b-2b02-64527227fcc1@cs.ucla.edu> Date: Tue, 15 Nov 2022 15:09:19 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: How can Autoconf help with the transition to stricter compilation defaults? Content-Language: en-US To: Aaron Ballman Cc: Jonathan Wakely , 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> <9cb106e9-16ff-65ec-6a44-6567c77521dc@cs.ucla.edu> <06a5d2cd-44eb-7404-17f3-ff64dd505427@cs.ucla.edu> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 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: >> Can you cite any examples of a real-world security flaw what would be >> found by Clang erroring out because 'char foo(void);' is the wrong >> prototype? Is it plausible that any such security flaw exists? > CVE-2006-1174 is a possibly reasonable example. CVE-2006-1174 is not an example, because no prototype 'char foo(void);' was involved.[1] Here's a more concrete proposal that should allay any realistic concerns about CVEs. If Clang decides to change its behavior in this area, so that Clang starts to exit with nonzero status if the user declares a function with a prototype incompatible with the C library, it would be a service to real users if Clang merely issues a warning and does *not* error out if the declaration is 'char foo();' (current Autoconf) or 'char foo(void);' (future Autoconf). This may be a hack, but it's a *good* hack. It's likely to fix real-world bugs that would be caused if Clang becomes overly pedantic by default here. And the probability of introducing real-world bugs is essentially zero. > You can run into that same bug > with use of `-Werror` That's OK, as the Autoconf documentation already says "don't do that". And if Clang exits with nonzero status in the above situation when -Werror is specified, that's fine too. [1] CVE-2006-1174 is not even an example of prototype mismatch, as the bad C code did not misdeclare the function in question: it used a POSIX standard include file for the function prototype, which is the standard way to do things.