From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) by sourceware.org (Postfix) with ESMTPS id 004F13858D20 for ; Fri, 11 Nov 2022 15:11:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 004F13858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=aaronballman.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=aaronballman.com Received: by mail-qt1-x834.google.com with SMTP id l2so2795454qtq.11 for ; Fri, 11 Nov 2022 07:11:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aaronballman.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7ZEe6uR6EEAIDSQ1gL8Q0/QnooGhVx5c21PROvpLZhM=; b=CqXzgrbrYg5OFNMGkDMVVdhtpS0EGKZ+LPWsAEJ5logSJvQDsKnNHQUcnzkIWKCE1a 2LcbuhO0I+cO6YE2KPJghFVTq4DV7ZvKjgOIg0s+qRHP6I7OhhVr2T4VZvXiEQqw9W/U zdIWIbb3rh0Ct8Wp0A0BDpUlhM3tu4QTpMWr8NOvqjfTC8KlCKG7dk9H3gODwr0SjoF6 i1F0N9F0tx4+P59Ub+cQFJT6YIXPhREh3613EyiA5ZsC2Q7FCB7BBhzqBHJxk/z48vir G6Yuag3yDdiVEN8oSrleEbFAz4onP09PKP5oxd1mFObJ/mcQ4/eRS8k67NncCDGq0OUM sJLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7ZEe6uR6EEAIDSQ1gL8Q0/QnooGhVx5c21PROvpLZhM=; b=DOxArmCbeOFxSP4jddOBKodjmBhmP/bHLO+JFycMb7CA8B3fag/yMrEDTjE9EyMnZ6 650nGLa+OQyycd+BEI7Tku/EsDm5cX2c1J1C+MaEK7MzV2Yas21rPG50KyeywUVrSOk1 CC4ZCa8j8+WgDX+aQR9OL3CblEiZGu6caytUEckjkk8QijtaboazT83vvf2U7bnxLWgM kd8xAO3CiOyEck86bidPOYAS3+/lfXvuwCEw53nDAPjGlHCKlYPnGrW6tdPohw5Ux1Sb 73I+jEQUc4dKM9VWpNekJ/MFOWsRv+/fsBS8QxW4/xC4DJsxCEBlJ01HnHLY9xrq8hPy iXcA== X-Gm-Message-State: ANoB5pkdRvx6zx1SUZkEplzdpwWMtcGLDjiG+C+Nww6qwCCTgg0KFINM yS8usBjpCzxTe20rjweJYIgLRuG/TG7khU8v X-Google-Smtp-Source: AA0mqf4b1tH/ZGkWvuzV2ChdZUXTNWSQxPpq2ybv6Rx2JH9bxcwKsu9AK19hnSloCXUNQKNvSBUrGQ== X-Received: by 2002:ac8:678c:0:b0:393:2901:1587 with SMTP id b12-20020ac8678c000000b0039329011587mr1611413qtp.661.1668179505108; Fri, 11 Nov 2022 07:11:45 -0800 (PST) Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com. [209.85.219.171]) by smtp.gmail.com with ESMTPSA id de38-20020a05620a372600b006bb87c4833asm1544063qkb.109.2022.11.11.07.11.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Nov 2022 07:11:43 -0800 (PST) Received: by mail-yb1-f171.google.com with SMTP id r3so6181848yba.5 for ; Fri, 11 Nov 2022 07:11:43 -0800 (PST) X-Received: by 2002:a25:d782:0:b0:6cb:7c9b:79da with SMTP id o124-20020a25d782000000b006cb7c9b79damr2064437ybg.389.1668179502603; Fri, 11 Nov 2022 07:11:42 -0800 (PST) MIME-Version: 1.0 References: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> <251923e7-57be-1611-be10-49c3067adf0d@cs.ucla.edu> In-Reply-To: <251923e7-57be-1611-be10-49c3067adf0d@cs.ucla.edu> From: Aaron Ballman Date: Fri, 11 Nov 2022 10:11:30 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: How can Autoconf help with the transition to stricter compilation defaults? To: Paul Eggert Cc: Zack Weinberg , c-std-porting@lists.linux.dev, autoconf@gnu.org, gcc@gcc.gnu.org, cfe-commits@lists.llvm.org, Gnulib bugs Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,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 Thu, Nov 10, 2022 at 4:05 PM Paul Eggert wrote: > > 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. FWIW, the only thing the (Clang) compiler is aware of is translation. So from the frontend perspective, we can't tell the difference between "trust me this is safe because it never gets executed" and "this is a CVE". We believe the runtime behavior is sufficiently dangerous to warrant a conservative view that any call to a function will be a call that gets executed at runtime, hence a definitive signature mismatch is something we feel comfortable diagnosing (in some form) by default. > 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. Clang doesn't require such a linker (we work with various system linkers). > 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. This would be challenging for an implementation like Clang where we work with an arbitrary C runtime library (which may be dynamically loaded on the target machine) and an arbitrary linker. ~Aaron