From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id BA3633858D28; Tue,  2 Apr 2024 16:04:33 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BA3633858D28
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1712073873;
	bh=ePoPNkCa+ARnXUQqDIdTklMv0O/zg+a6J1G4NRBSFJ0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=XVqV26uIuUF27/tqBijfZi89zyLuhBu2FVITT9PvXA1Zy/Vx2GipM2JICOiwt7Nsz
	 rmgtgtTMeFem2MsDuDd8giiSdXtEzBssIs0Yezl9TNWLFkhR8YzQTuGyQdksJqRn1U
	 TwsdO6hjqpKOsi0aD7Vqn7EUFqvsaVXxVzu6Wju4=
From: "jsm28 at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/114526] ISO C does not prohibit extensions: fix
 misconception.
Date: Tue, 02 Apr 2024 16:04:32 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: diagnostic, documentation
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jsm28 at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: DUPLICATE
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-114526-4-hVOx3NyHYU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114526-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114526-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114526

--- Comment #8 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
"rejects", in the ISO C sense, only applies to errors and pedwarns in GCC; =
not
to warnings conditional on -pedantic (of which there are also some, but whi=
ch
don't turn into errors with -pedantic).

If you have cases where something that is only *undefined as a property of a
particular execution of the program* (as opposed to undefined as a property=
 of
a translation unit or of the collection of translation units making up a
program, or violating a Constraint or syntax rule) but that are errors or
pedwarns, those should be reported as separate bugs. There are various cases
where we make sure to only warn at compilation time and generate code that
aborts at precisely the point in execution where undefined behavior would
occur, precisely because the undefined behavior in those cases is a propert=
y of
a program execution.

I believe conversions between function and object pointers are undefined as=
 a
property of the translation unit - not of a particular execution. Whereas e=
.g.
calling a function pointer converted to an incompatible type is undefined a=
s a
property of a particular execution (the undefinedness only occurring when t=
he
call itself is executed, after all side effects from the function designator
and arguments have taken place).=