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 C34163858D3C for ; Thu, 10 Nov 2022 21:05:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C34163858D3C 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 46E9216004F; Thu, 10 Nov 2022 13:05:58 -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 obCoDUKhz0K3; Thu, 10 Nov 2022 13:05:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5313F160072; Thu, 10 Nov 2022 13:05:57 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 5313F160072 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1668114357; bh=m9vhYki69Y/pjN0Au3N7NJJfK+ukveZ5AzANx1bPd18=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=Q5aUwbU9mjLb1hlygesP8N2Dl9QaR6J+RGeEgWYN2EMF6MehKNVegVjy76MigV7NC hiyWBPee+7D3XJdsNFvttoDp3vMHLD6JOQQCUE/Lxr1xNPRFRzcv2BLS8iQo8Xt6St N2T+Q3ASXnooSAk8voFdANgh3n0QZd5aU3y1kmjw= 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 ebuw5gua4Zp8; Thu, 10 Nov 2022 13:05:57 -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 1A6A5160046; Thu, 10 Nov 2022 13:05:57 -0800 (PST) Message-ID: <251923e7-57be-1611-be10-49c3067adf0d@cs.ucla.edu> Date: Thu, 10 Nov 2022 13:05:56 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3 Content-Language: en-US To: Aaron Ballman , Zack Weinberg Cc: 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> 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.5 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-10 10:19, Aaron Ballman wrote: > In terms of the Clang side of things, I don't think we've formed any > sort of official stance on how to handle that yet. It's UB (you can > declare the C standard library interface without UB but calling any > function with a mismatched signature is UB) The Autoconf-generated code is never executed, so this is not a runtime issue; it's merely an issue of undefined behavior during translation. A problem could occur with a picky compiler or linker that rejects modules with mismatched function type declarations. Does Clang do that, or require or use such a linker? If not, there's no practical problem here. If so, it'd be helpful if Clang continued to support its traditional behavior that doesn't reject Autoconf's test cases, and for this to be the default. Autoconf arose because one cannot ask something like "Can I call the renameat2 function with its usual signature?" in standard C code and one must escape into something like the shell to handle such questions. C23 and GCC and Clang have added a few features to answer such questions, such as __has_include. But these features don't go nearly far enough. For example, __has_include tells me only whether the include file exists; it won't tell me whether I can successfully include , or whether will declare the function 'bar', or whether 'bar' will have a signature compatible with my code's calls to 'bar'. If I could request a single thing from the C23/GCC/Clang side, I'd ask for better facilities to be able to ask such questions within C code, without using the shell. Then a good chunk of Autoconf could dry up and blow away. I realize that I'm asking for a lot. For example, a traditional implementation cannot answer the renameat2 question without consulting the linker. That being said, this ability is essential for modular programming at the low level, and if compilers don't provide this ability Autoconf will simply have to do the best it can, regardless of whether it generates source code that relies on undefined behavior.