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.0 required=3.0 tests=AWL,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 729F51F910 for ; Wed, 16 Nov 2022 16:46:40 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="li5a46WX"; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ovLYK-0008DD-7a; Wed, 16 Nov 2022 11:46:20 -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 1ovLYH-00087O-VO; Wed, 16 Nov 2022 11:46:17 -0500 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ovLYF-0001Mn-T5; Wed, 16 Nov 2022 11:46:17 -0500 Received: by mail-ed1-x529.google.com with SMTP id s12so27412012edd.5; Wed, 16 Nov 2022 08:46:14 -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=96qCR0dYwW/H3EuuUIXpMcnUqIruy0qbY8DUamTil9E=; b=li5a46WXwm+pPPJIyZqmuTTtIBBuoMN0i9qetV7Vh0rmjYc+Jh9Oa8idSA7qyg9UCR F2mDJpSOoLRsHP8mS/GgXVzAKu/lnNCvwr+gmR5++tefRIHVN5yiQTHyTAOISZyGOqMT 0YrFlsjEU1+aoWamLvBfpXpagY7IXcd5CBRd2f61NaJXmOhGmxGxm/8IVnJAUiKpxz2R 78WcwNHSbkF8TVPjqqW5A3esdgaR+iNvZu7Z3Whxvcwr+cAzJpWkggmGyFJx1/VLgmBm vgOYke5SPK3iqxAB8FD5gj6rHGbPcWn6Lsd7i/k/0pcM2tddlZHJsZbLKEi2I4bfsvf3 RUSA== 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=96qCR0dYwW/H3EuuUIXpMcnUqIruy0qbY8DUamTil9E=; b=uawjRJTfDRAuk+MGo1u4mVFc9kup84nx21Kt6dlk0K12WupXSPCLCjFJ6qlX14e/O5 Ih1b1sqBCSUo59bytbErnFLE2e6hK6XRdUvUC6VJ5Dn3t2vz2B+FVVpeezhKTpliid2L ln9Ej9qji7vYx8TgL2HSjUQQyQAp20xgBTIgPtU90MBhvZy1YsL/E0f8yAgE+uO/cvIP trB187DAhffSj9ViVLNBSHyL/0ofV1zKkkca3dUZF146JgIVGn2pIbFlrO0qcI8MQH69 KNF/R5eVoU5x/7VFI8jPMdjqGpU6qGkUlf4DOOB0JZAfHXH/3/LgmTHxoDJDelmnZ0R7 gP+A== X-Gm-Message-State: ANoB5pniv7iZuf1oglosMZJUfslpyd8Nw/fJAOuFExtJUwUz/pck7W4w W4uIQTDVmW28n714xhMlUY6vxMLt9CBWpUIrX9Q= X-Google-Smtp-Source: AA0mqf76o0R0CRUzDbJCrgJZkVmTLRhzlnxY+nLOtcNDm23FBkb6LBc3J9hNft0l1zpDgv1o/gQPbLulpq9LH07h2rI= X-Received: by 2002:a50:9557:0:b0:45c:f13b:4b96 with SMTP id v23-20020a509557000000b0045cf13b4b96mr19638390eda.129.1668617172797; Wed, 16 Nov 2022 08:46:12 -0800 (PST) MIME-Version: 1.0 References: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> <7ef0ce03-d908-649a-a6ee-89fea374d2b1@cs.ucla.edu> <9cb106e9-16ff-65ec-6a44-6567c77521dc@cs.ucla.edu> <06a5d2cd-44eb-7404-17f3-ff64dd505427@cs.ucla.edu> <27264d94-9496-d7ef-6716-f43db86f38e2@ispras.ru> <00C3EDCD-D2DA-4B0D-8A8A-08B76552D865@gentoo.org> In-Reply-To: From: Jonathan Wakely Date: Wed, 16 Nov 2022 16:46:01 +0000 Message-ID: Subject: Re: How can Autoconf help with the transition to stricter compilation defaults? To: Michael Matz Cc: Sam James , Richard Biener , Aaron Ballman , Alexander Monakov , Paul Eggert , Zack Weinberg , c-std-porting@lists.linux.dev, Autoconf Development , GCC Development , cfe-commits@lists.llvm.org, Gnulib bugs Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::529; envelope-from=jwakely.gcc@gmail.com; helo=mail-ed1-x529.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-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 at 16:34, Michael Matz wrote: > > Hello, > > On Wed, 16 Nov 2022, Jonathan Wakely wrote: > > > > > Unrelated but I was a bit tempted to ask for throwing in > > > > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at > > > > it, but I suppose we don't want the world to burn too much, > > > > > > :-) It's IMHO a bug in the standard that it misses "if any of its > > > associated headers are included" in the item for reservation of external > > > linkage identifiers; it has that for all other items about reserved > > > identifiers in the Library clause. If that restriction were added you > > > couldn't justify erroring on the example at hand (because it doesn't > > > include e.g. and then printf wouldn't be reserved). A warning > > > is of course always okay and reasonable. As is, you could justify > > > erroring out, but I too think that would be overzealous. > > > > > > I think that's very intentional and not a defect in the standard. > > > > If one TU was allowed to define: > > > > void printf() { } > > > > and have that compiled into the program, then that would cause > > unexpected behaviour for every other TU which includes and > > calls printf. They would get the non-standard rogue printf. > > True. But suppose the restriction would be added. I could argue that > then your problem program (in some other TU) _does_ include the header, > hence the identifier would have been reserved and so the above definition > would have been wrong. I.e. I think adding the restriction wouldn't allow > the problematic situation either. > > I'm aware that the argument would then invoke all the usual problems of > what constitutes a full program, and if that includes the library even > when not including headers and so on. And in any case currently the > standard does say they're reserved so it's idle speculation anyway :) Since we're idly speculating anyway ... I'd always assumed the "if any of its associated headers is included" meant in the current TU, but it doesn't actually say that. Which does suggest that I can't use the identifier "assert" anywhere in a program if any TU in the program includes . Huh.