From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id 1C7C73832343 for ; Wed, 16 Nov 2022 14:26:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1C7C73832343 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 24D5E336FA; Wed, 16 Nov 2022 14:26:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1668608814; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Wl2xR7lAqFVSqzmqm7GiC2VR9RHLJrGZsjAMvnDg4EI=; b=aatVsvaQhwYxhS4/EJ+2TchLG0t8jKqh3trP3xVTzn5fQn8GF8ABBEzgvB7dZh/unryknK GRQn2gFi8vVSzrBldtwKemOUIUqrk4SvTQ9gIfOWHYiusQAZLR8Sp9td3sD+psNpTLfPz4 cIpqbFZV5Yib38uFnxGKBTYg87SlmMI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1668608814; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Wl2xR7lAqFVSqzmqm7GiC2VR9RHLJrGZsjAMvnDg4EI=; b=0ZecJZ4QT7X8YsnSE9gePl6/tjNAoCjjQENAMZpdwxy7Zid53Kf94Uy3jIQHakF5adMedk cK4BE8JIJJJfgkCw== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 488FB2C141; Wed, 16 Nov 2022 14:26:52 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id EB08D6583; Wed, 16 Nov 2022 14:26:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id E9A4364AC; Wed, 16 Nov 2022 14:26:52 +0000 (UTC) Date: Wed, 16 Nov 2022 14:26:52 +0000 (UTC) From: Michael Matz To: Paul Eggert cc: Jonathan Wakely , Aaron Ballman , Zack Weinberg , c-std-porting@lists.linux.dev, autoconf@gnu.org, gcc@gcc.gnu.org, cfe-commits@lists.llvm.org, Gnulib bugs Subject: Re: How can Autoconf help with the transition to stricter compilation defaults? In-Reply-To: <06a5d2cd-44eb-7404-17f3-ff64dd505427@cs.ucla.edu> Message-ID: 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> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, On Tue, 15 Nov 2022, Paul Eggert wrote: > On 2022-11-15 11:27, Jonathan Wakely wrote: > > Another perspective is that autoconf shouldn't get in the way of > > making the C and C++ toolchain more secure by default. > > 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? > > On the contrary, it's more likely that Clang's erroring out here would > *introduce* a security flaw, because it would cause 'configure' to > incorrectly infer that an important security-relevant function is > missing and that a flawed substitute needs to be used. > > Let's focus on real problems rather than worrying about imaginary ones. I sympathize, and I would think a compiler emitting an error (not a warning) in the situation at hand (in absence of -Werror) is overly pedantic. But, could autoconf perhaps avoid the problem? AFAICS the ac_fn_c_check_func really does only a link test to check for symbol existence, and the perceived problem is that the call statement in main() invokes UB. So, let's avoid the call then while retaining the access to the symbol? Like: ----- char foobar(void); int main(void) { return &foobar != 0; } ----- No call involved: no reason for compiler to complain. The prototype decl itself will still be "wrong", but compilers complaining about that (in absence of a pre-existing different prototype, which is avoided by autoconf) seem unlikely. Obviously this program will also say "foobar exists" if it's a data symbol, but that's the same with the variant using the call on most platforms (after all it's not run). The idea is so obvious that I'm probably missing something, why autoconf can't use that idiom instead. But perhaps the (historic?) reasons why it couldn't be used are gone now? Ciao, Michael.