From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id 67F9F395B472 for ; Wed, 16 Nov 2022 16:34:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 67F9F395B472 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 3E1E81F957; Wed, 16 Nov 2022 16:34:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1668616478; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uXc5c5wQrBwgDBlWPMaqc5w4FdhBB0Wf/wm9YRQTaho=; b=zVu47M6mPMvDTvvxMNRZbSbc0otQWhEfQ0VeTHzbOjTes2InPtdWGjWH3AXjgWK8rM4AQE N7erLQv/zdhNUeoNKglRPMrG4pEu1rWbZ2oP9Ncqq2pfHc9M79Vt2DbVjy/uPrzEEx5fDf kgIHoHYjOkjAWL3Ky99By+ObSJkbnkQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1668616478; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uXc5c5wQrBwgDBlWPMaqc5w4FdhBB0Wf/wm9YRQTaho=; b=D0zhgQ/J9Q0njpQqoNRE4YE65wAf4etRD7tClrX2e2u+jtI6nk9HF0r0PvDzX3EiGDdB8p a120zXegy/Uy5qBA== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 070FE2C141; Wed, 16 Nov 2022 16:34:38 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id F23176570; Wed, 16 Nov 2022 16:34:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id EEE406332; Wed, 16 Nov 2022 16:34:37 +0000 (UTC) Date: Wed, 16 Nov 2022 16:34:37 +0000 (UTC) From: Michael Matz To: Jonathan Wakely 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 Subject: Re: How can Autoconf help with the transition to stricter compilation defaults? In-Reply-To: Message-ID: 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> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: 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 :) Ciao, Michael.