From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id E9DD03896C11 for ; Tue, 15 Nov 2022 14:50:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E9DD03896C11 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x631.google.com with SMTP id n20so16019965ejh.0 for ; Tue, 15 Nov 2022 06:50:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3KCQTaZPd5CAD9nwawsyv7u4EktWAiK50Kn8Cfprv+g=; b=Zp50GTSoeDQPrP7eESYrmdFDVo4JLC2p348UaKo3kPUJ5Ke7fPgJhejMU7LVl7P3aS BtbryhzBPSqAbngPxnUlOISVxcV8wuKh/9AExdQfuSFyWLSkwnsBSbFdSrQU0dMWtN+M C+dinZCjHPfhTH40ErB3ui78Ip04EAkQMEdk0cxs/CVxYFsCh5ws9EE0baKFQXzLJ1P6 4EwnYsJemKQ0wCE6yFt9EZY7M13pjFjoMWUnb5TsaNJuuz6/o28pMTHNHqnjcn3n3L9n zC42litsO+Ielqs1pO+TfDknja9yW6SVyBAyDxWmMmHBzwxK3z+yFgVJvWNjgokmn8+3 fBCg== 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=3KCQTaZPd5CAD9nwawsyv7u4EktWAiK50Kn8Cfprv+g=; b=gG4HP8XUdSE3650Cc8UGlJwmBwfaCexlRJ8LzhmkXaTdg2YwAxs4HfY4HgrIWn3RSa c4V6HHbsgsQLcL0v6RbFekmjt3AWKviY7ix+Q4XGhagGj8sDBvgPCU5OrYc+ytiMmOfo urAZqYVnPkx+qmwZFE+03nIAQz7zSwAyS65LQkNaCyNJWQM8aBCenyygWSM24wvZ4ND9 B3/4TKU0+pDtf785nVEciuQPjlSJcht1NhvLNQNDdnBgKC7Q9dhtrtpyeVH8n5PNUXUN NPABtpXoKd/5aBEsYpfYD9ZnUQBbAOkH80JQiE+LpCO1Tg4BLAr+sQHy6z90PW2Iu0GY XM6w== X-Gm-Message-State: ANoB5pnTAemcS0HNDzajl9NBWsGReJKmOcEkaNuvho3WQ6cQAEbc6zEJ /5BFkSEkP25DjpK9Vc2T57YHSPksW2zxt7krxHA= X-Google-Smtp-Source: AA0mqf7rQ2BKFtis7IXgwF1R226/HgRigNmRzN6sTC39ODmPkx/zxaEb7fB9uaLTZMbCLYs3Qd18Gj0715xfc0gi4wc= X-Received: by 2002:a17:906:1597:b0:7ad:ba48:7e7f with SMTP id k23-20020a170906159700b007adba487e7fmr13900508ejd.215.1668523852387; Tue, 15 Nov 2022 06:50:52 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Jonathan Wakely Date: Tue, 15 Nov 2022 14:50:41 +0000 Message-ID: Subject: Re: How can Autoconf help with the transition to stricter compilation defaults? To: Paul Eggert Cc: Aaron Ballman , 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=-0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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 Mon, 14 Nov 2022 at 18:15, Paul Eggert wrote: > > On 2022-11-14 04:41, Aaron Ballman wrote: > > it's generally a problem when autoconf relies on invalid > > language constructs > > Autoconf *must* rely on invalid language constructs, if only to test > whether the language constructs work. And Clang therefore must be > careful about how it diagnoses invalid constructs. Clang shouldn't > willy-nilly change the way it reports invalid constructs, as that can > break Autoconf. There's a difference between checking whether an invalid construct works, where that construct is the subject of the test, and incidentally relying on invalid language constructs as part of testing for other things. > > issues of security > > like statically known instances of UB > > It's fine to report those; I'm not saying don't report them. All I'm > saying is that Clang should be careful about *how* it reports them. Could you clarify what you mean, with a concrete example? Surely as long as errors are reported on stderr and the compiler exits with non-zero status, that's an acceptable way to report errors? What kind of changes to error reporting are you saying to be careful with? If Clang starts to diagnose a given provable-UB case (or any other construct) as an error instead of a warning, then it seems entirely correct for autoconf to report that the case does not work. That's the desired behaviour, isn't it? What we don't want is for autoconf to start reporting that *other* things don't work, as a result of autoconf relying on UB or ill-formed code when trying to check other things like the presence of function 'foo'. And that's why autoconf should avoid using invalid/undefined code when possible. > > At the very least if there are going to be changes in this area, the > Clang developers should notify Autoconf (and presumably other) > downstream users of the changes, and provide a supported way to get the > old behavior for reporting, and give downstream time to adapt.