public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
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 18:18:15 +0000	[thread overview]
Message-ID: <bug-114526-4-0uSz7PiXnv@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-114526-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #15 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
There are several statements such as "Any pointer type may be converted to an
integer type." and "A pointer to an object type may be converted to a pointer
to a different object type.", that allow certain conversions to occur in a
translation unit and are associated with some properties of those conversions
if they are executed. There are also statements disallowing certain conversions
from occurring in a translation unit (for example, conversions between pointer
and floating types are constraint violations). In the cases where there is no
statement either way, the behavior is undefined as a property of the
translation unit (not just of the execution): it is not defined whether such a
conversion may occur in a translation unit, and not defined what the semantics
would be on execution if an implementation permits the translation of such a
conversion. Being undefined through omission of definition has, as per clause
4, not difference in meaning or emphasis from being explicitly undefined.

I'd suggest working with the Undefined Behavior Study Group on making it more
explicit for each instance of undefined behavior whether it is a property of
the program or of an execution thereof, but if any case seems particularly
unclear, filing an issue once the new C standard issue tracker is up and
running would probably be reasonable (but it seems likely that such issues
would be referred to the UB study group to recommend a resolution just as
floating-point issues would likely be referred to the CFP group).

It's *not* the case that the same rules apply everywhere, because there are two
different kinds of UB depending on whether what's undefined is a property of
the program or an execution thereof. Division by zero is obviously UB as a
property of an execution, because whether a value is zero is a property of the
execution. Different types for the same identifier with external linkage in
different translation units is obviously UB as a property of the program (and
not widely diagnosed without LTO), as the whole concept of an identifier
corresponding to an object with a particular value depends on a globally
consistent notion of its type and the UB is about presence of declarations
rather than a particular path of execution. In some cases, as here, it may be
less obvious how to read the wording as referring to properties of an execution
or of a program.

  parent reply	other threads:[~2024-04-02 18:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-28 22:00 [Bug c/114526] New: " kkylheku at gmail dot com
2024-03-28 22:03 ` [Bug c/114526] " pinskia at gcc dot gnu.org
2024-03-28 22:06 ` pinskia at gcc dot gnu.org
2024-03-28 22:33 ` kkylheku at gmail dot com
2024-03-29  0:27 ` harald at gigawatt dot nl
2024-03-29  1:20 ` jsm28 at gcc dot gnu.org
2024-03-29  1:23 ` harald at gigawatt dot nl
2024-03-29  3:07 ` kkylheku at gmail dot com
2024-04-02 16:04 ` jsm28 at gcc dot gnu.org
2024-04-02 16:16 ` harald at gigawatt dot nl
2024-04-02 16:20 ` harald at gigawatt dot nl
2024-04-02 17:21 ` jsm28 at gcc dot gnu.org
2024-04-02 17:29 ` kkylheku at gmail dot com
2024-04-02 17:35 ` kkylheku at gmail dot com
2024-04-02 17:57 ` harald at gigawatt dot nl
2024-04-02 18:18 ` jsm28 at gcc dot gnu.org [this message]
2024-04-02 19:06 ` harald at gigawatt dot nl
2024-04-02 19:41 ` kkylheku at gmail dot com
2024-04-02 21:37 ` harald at gigawatt dot nl
2024-04-03  5:48 ` kkylheku at gmail dot com
2024-04-03  8:07 ` harald at gigawatt dot nl

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=bug-114526-4-0uSz7PiXnv@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.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).