From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id A66691F910 for ; Wed, 16 Nov 2022 15:50:30 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ovKg7-0005tn-3g; Wed, 16 Nov 2022 10:50:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ovJbB-0008IN-C3; Wed, 16 Nov 2022 09:41:09 -0500 Received: from mail.ispras.ru ([83.149.199.84]) by eggs.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ovJb9-0006rv-69; Wed, 16 Nov 2022 09:41:09 -0500 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 Received-SPF: pass client-ip=83.149.199.84; envelope-from=amonakov@ispras.ru; helo=mail.ispras.ru X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 16 Nov 2022 10:50:17 -0500 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org 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