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 D63213858D32; Tue,  2 Apr 2024 17:29:05 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D63213858D32
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1712078945;
	bh=sVJyaSvBHlXtYLOZHWfWPzDA1QgT8crFkYHaPETtWy0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=OGb3oDQT+lgtrTUo51f+E2sgrfwuF4Imcjvj1oF35iS+4pfW/aGEzEdOYwv6DIToH
	 e3lzcZkOfuSISZlAtU1Z7dSSEokc2+S5Cw5VQnAkGNU8J+EvA7fQSDq/7kwl/0cELq
	 3XEpfWEPZN1X0cIo4yfe1wsF6GuejHhEj/DooCrU=
From: "kkylheku at gmail dot com" <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 17:29:05 +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: kkylheku at gmail dot com
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-7X870Pcj2p@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 #12 from Kaz Kylheku <kkylheku at gmail dot com> ---
(In reply to Harald van Dijk from comment #10)
> Sorry, sent my earlier comment too soon.
>=20
> (In reply to Joseph S. Myers from comment #8)
> > I believe conversions between function and object pointers are undefine=
d as
> > a property of the translation unit - not of a particular execution.
>=20
> But there is nothing in the standard to support this. The standard fully
> defines the behaviour of the program I posted, which is just to return 0.

It does not. You're relying on the implementation (1) glossing over the
undefined conversion at translation time (or supporting it as an extension)=
 and
then (2) optimization removing whatever code was generated for it since the
value is unused.

The standard does not define the conversion, by omission of defined behavio=
r.

Moreover, the omission isn't absolute. There is a non-normative mention of =
this
conversion in an informative Annex which acknowledges the conversion as a
common extension. That tells us that the omission of a definition of behavi=
or
from the normative text is known, and deliberate.

Undefined behavior means that the implementation is permitted to stop, at
translation or execution time, with or without the issuance of a diagnostic
message.

Moreover, implementations are not required to optimize. If the abstract
semantics of your program is executed literally, then there will be an
undefined conversion performed, whose value is then discarded in the
expression-statement.=