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=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 CD33A1F910 for ; Tue, 15 Nov 2022 15:08:37 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="Zp50GTSo"; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ouxXd-0001ox-Vb; Tue, 15 Nov 2022 10:08:01 -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 1ouxH6-0000jj-KK; Tue, 15 Nov 2022 09:51:05 -0500 Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ouxH4-0000Ys-UD; Tue, 15 Nov 2022 09:50:56 -0500 Received: by mail-ej1-x62c.google.com with SMTP id f18so3597977ejz.5; 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=34MoI38HySs/sDjsAYR1iBHfbBWpLTWAEUXRuEINBGI2kV1XPb9wUdQddeuB8W6AO5 JMTrnT8pzoNEna0HEMtndSYHzjNzNsjYCP4sXfdbuTK5kk9r+Is67c1KLdzMOUwKyRiE R4YtN3ZtgXq91opG0/Czgd7Glx7sjYkrc9dA+WLiD6ByY4LnUNHJbg2q3eeN6D+xz8j+ y1ZhUHoAq2voq30X3pHuL/eWZp928TGfmqv0N6cUqL54Sz3VnDRKMwkGDr+KISmBdsqq FbMRPIi8bDJbxsZF/FopwTWWcPU2l2CipW5NDKVc7LITAgRhqI5ZNjfTls62RvpShmLC /Bew== X-Gm-Message-State: ANoB5pl3v5d3gZShEr2taP12hR7jrVmpCeNHiAwpC/pDlzqVZynvWyUt ofgdnOT2r7wRryrFl0jQhZk0cpO5Lft0/OUrcRRkMyVa 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" Received-SPF: pass client-ip=2a00:1450:4864:20::62c; envelope-from=jwakely.gcc@gmail.com; helo=mail-ej1-x62c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 15 Nov 2022 10:07:59 -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 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.