public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Michael Matz <matz@suse.de>
To: Jonathan Wakely <jwakely.gcc@gmail.com>
Cc: Sam James <sam@gentoo.org>,
	Richard Biener <richard.guenther@gmail.com>,
	 Aaron Ballman <aaron@aaronballman.com>,
	 Alexander Monakov <amonakov@ispras.ru>,
	Paul Eggert <eggert@cs.ucla.edu>,
	 Zack Weinberg <zack@owlfolio.org>,
	c-std-porting@lists.linux.dev,
	 Autoconf Development <autoconf@gnu.org>,
	GCC Development <gcc@gcc.gnu.org>,
	 cfe-commits@lists.llvm.org, Gnulib bugs <bug-gnulib@gnu.org>
Subject: Re: How can Autoconf help with the transition to stricter compilation defaults?
Date: Wed, 16 Nov 2022 16:34:37 +0000 (UTC)	[thread overview]
Message-ID: <alpine.LSU.2.20.2211161627390.5466@wotan.suse.de> (raw)
In-Reply-To: <CAH6eHdSfGxFBhkuCgykUxyWjyTN3LVa_H4-b728eJVb4YKQjgA@mail.gmail.com>

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. <stdio.h> 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 <stdio.h> 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.

  reply	other threads:[~2022-11-16 16:34 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-10 17:16 Zack Weinberg
2022-11-10 17:52 ` Nick Bowler
2022-11-10 17:58   ` Jonathan Wakely
2022-11-10 18:12     ` Jonathan Wakely
2022-11-10 18:44       ` Aaron Ballman
2022-11-12  2:56   ` Zack Weinberg
2022-11-10 18:05 ` Rich Felker
2022-11-10 21:44   ` Florian Weimer
2022-11-12  3:22   ` Zack Weinberg
2022-11-10 18:08 ` Florian Weimer
2022-11-12  3:40   ` Zack Weinberg
2022-11-12  3:43     ` Sam James
2022-11-12 14:27       ` Zack Weinberg
2022-11-12  3:45     ` Joseph Myers
2022-11-12 15:59   ` Wookey
2022-11-12 16:12     ` Zack Weinberg
2022-11-10 18:19 ` Aaron Ballman
2022-11-10 21:05   ` Paul Eggert
2022-11-11 15:11     ` Aaron Ballman
2022-11-13  0:43       ` Paul Eggert
2022-11-14 12:41         ` Aaron Ballman
2022-11-14 18:14           ` Paul Eggert
2022-11-14 18:30             ` Florian Weimer
2022-11-14 18:35             ` Aaron Ballman
2022-11-15 14:50             ` Jonathan Wakely
2022-11-15 19:08               ` Paul Eggert
2022-11-15 19:27                 ` Jonathan Wakely
2022-11-15 20:27                   ` Paul Eggert
2022-11-15 20:57                     ` Aaron Ballman
2022-11-15 23:09                       ` Paul Eggert
2022-11-15 23:43                         ` Ben Boeckel
2022-11-16 14:26                     ` Michael Matz
2022-11-16 14:40                       ` Alexander Monakov
2022-11-16 15:01                         ` Michael Matz
2022-11-16 15:27                           ` Richard Biener
2022-11-16 15:35                             ` Sam James
2022-11-16 15:59                               ` Michael Matz
2022-11-16 16:20                                 ` Jonathan Wakely
2022-11-16 16:34                                   ` Michael Matz [this message]
2022-11-16 16:46                                     ` Jonathan Wakely
2022-11-16 18:17                       ` Paul Eggert
2022-11-16 18:40                         ` Jeffrey Walton
2022-11-17 18:45                           ` Paul Eggert
2022-11-16 18:59                         ` Zack Weinberg
2022-11-17 18:58                           ` Paul Eggert
2022-11-17 21:35                             ` Bruno Haible
2022-11-17 22:27                               ` Paul Eggert
2022-11-17 13:30                         ` Michael Matz
2022-11-15 20:36                 ` Aaron Ballman
2022-11-15  5:03         ` Sam James
2022-11-15 13:30           ` Zack Weinberg
2022-11-15 13:34             ` Sam James
2022-11-16  0:08           ` Bob Friesenhahn
2022-11-13  0:43       ` Paul Eggert
2022-11-17 13:57         ` Jason Merrill
2022-11-10 20:19 ` Paul Eggert
     [not found] ` <d785b19371e8419f5a5817d7cdb429db91614a3a.camel@orlitzky.com>
2022-11-11  3:08   ` Sam James
2022-11-11  3:33     ` Zack Weinberg
2022-11-11  8:40       ` Sam James
2022-11-11  9:02       ` Paul Eggert
2022-11-12 14:09         ` Zack Weinberg
2022-11-11 23:25       ` Sam James
2022-11-12  0:53         ` Paul Eggert
2022-11-12  4:00           ` Sam James
2022-11-11  9:15 ` Sam James

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LSU.2.20.2211161627390.5466@wotan.suse.de \
    --to=matz@suse.de \
    --cc=aaron@aaronballman.com \
    --cc=amonakov@ispras.ru \
    --cc=autoconf@gnu.org \
    --cc=bug-gnulib@gnu.org \
    --cc=c-std-porting@lists.linux.dev \
    --cc=cfe-commits@lists.llvm.org \
    --cc=eggert@cs.ucla.edu \
    --cc=gcc@gcc.gnu.org \
    --cc=jwakely.gcc@gmail.com \
    --cc=richard.guenther@gmail.com \
    --cc=sam@gentoo.org \
    --cc=zack@owlfolio.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).