public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "harald at gigawatt dot nl" <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 19:06:30 +0000 [thread overview] Message-ID: <bug-114526-4-yP6Z8HOsb8@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 #16 from Harald van Dijk <harald at gigawatt dot nl> --- (In reply to Joseph S. Myers from comment #15) > 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, This is still not stated anywhere in the standard though. > Being undefined > through omission of definition has, as per clause 4, not difference in > meaning or emphasis from being explicitly undefined. Of course, but if the standard had explicitly stated that conversion between function pointers and object pointers was undefined, it might be phrased in a way that applies even to dead code. If you are relying on being undefined by omission, you have to be really sure the behaviour is not defined *anywhere*, including by general rules about dead code. I will grant that the standard never explicitly says dead code is not executed and has no effect, but if this is in dispute, we have a bigger problem. > 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). Considering my stance is that WG14 have repeatedly and consistently stated what the rules are, I see this as a waste of their time. > 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. Considering this example of 1/0 has been the subject of two separate DRs that I referenced, I have to say it is not obvious from the standard itself. Keeping in mind that the operands are constants and implementations are required to be capable of constant expression evaluation in some contexts, a hypothetical standard that permitted, or even required, this to be evaluated at translation time (with undefined behaviour) even in otherwise dead code would make perfect sense. But that is not the C standard we have, at least not the official interpretation of it. > 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. Yes, because a program that does not reference these identifiers still violates the rule that specifies they must have compatible type. This means that there is no execution of the program that avoids UB. But in my program, there is no rule that is violated. Perhaps the rule that you describe in your comment, that no program may contain any unsupported conversion anywhere, regardless of whether the conversion is ever performed, should exist, but it is simply not the case that there is such a rule to be found anywhere in the standard. One additional comment, though: The fact that conversions between function pointers and object pointers are rejected under -pedantic-errors mean that 'gcc -std=c99 -pedantic-errors' cannot be used as the implementation for POSIX's c99 utility, as POSIX's c99 utility is required to conform to the C99 standard, and simultaneously, permit conversions between function pointers and object pointers (at least in some cases). (Adjust for later versions as needed.) This is unfortunate, and regardless of whether the C standard allows such programs to be rejected, can we agree that the C standard also allows them to be accepted, and POSIX requires them to be accepted? Is that not already sufficient reason to reconsider?
next prev parent reply other threads:[~2024-04-02 19:06 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 2024-04-02 19:06 ` harald at gigawatt dot nl [this message] 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-yP6Z8HOsb8@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: linkBe 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).