From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) by sourceware.org (Postfix) with ESMTPS id E2F90395A422 for ; Wed, 16 Nov 2022 14:40:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E2F90395A422 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ispras.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ispras.ru Received: from [10.10.3.121] (unknown [10.10.3.121]) by mail.ispras.ru (Postfix) with ESMTPS id 49B6D419E9C5; Wed, 16 Nov 2022 14:40:42 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 49B6D419E9C5 Date: Wed, 16 Nov 2022 17:40:42 +0300 (MSK) From: Alexander Monakov To: Michael Matz cc: Paul Eggert , 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: Message-ID: <27264d94-9496-d7ef-6716-f43db86f38e2@ispras.ru> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,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: On Wed, 16 Nov 2022, Michael Matz via Gcc wrote: > 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? Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0, and thus no symbol reference remains in the resulting assembly. Alexander