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 17:57:28 +0000 [thread overview] Message-ID: <bug-114526-4-TkqC6rFCuc@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 #14 from Harald van Dijk <harald at gigawatt dot nl> --- (In reply to Joseph S. Myers from comment #11) > I think that simply failing to say whether a value of type X may be > converted to type Y is clearly enough for it at least to be unspecified > whether or when such conversions are possible in a cast at all (which is > enough for rejecting the translation unit). I disagree. You're reading something into the standard that it does not say anywhere. It would make sense if it did say that, but it doesn't. > And since no requirements are > imposed relating to such conversions at either translation time or runtime, > the definition of undefined behavior is met. The behaviour at runtime is implicitly unspecified. The behaviour at translation time is not, as my program does not attempt to convert between any function and object pointer. Performing that conversion is undefined by omission. Writing code that *would* perform that conversion, if executed, is not undefined, because the standard defines the behaviour of code that is not executed: it does nothing. I am assuming, at least, that there is no dispute that #include <stdio.h> int main(void) { if (0) puts("Hello, world!"); return 0; } has never been permitted to print "Hello, world!". (In reply to Kaz Kylheku from comment #12) > It does not. You're relying on the implementation (1) glossing over the > undefined conversion at translation time (or supporting it as an extension) I'm not. > Undefined behavior means that the implementation is permitted to stop, at > translation or execution time, with or without the issuance of a diagnostic > message. My program has no undefined behaviour. It is in the same category as void f(void) { 1/0; } int main(void) { return 0; } which is strictly confirming despite the division by zero in an uncalled function, despite division taking constant operands. The implementation is not at liberty to treat this as translation-time undefined behaviour, because the program does not divide by zero. Even though constant expressions could otherwise be optimised. And GCC rightly accepts this with -pedantic-errors. It is in the same category as void f(x) void *x; { f(f); } int main(void) { return 0; } which is strictly conforming despite the unevaluated function call to an unprototyped function with a wrong argument type where the compiler knows the type of the parameter. And GCC rightly accepts this too with -pedantic-errors. It does not even warn by default. There have been DRs that explicitly address this for various forms of undefined behaviour (#109, #132, #317). Is it really necessary for WG14 to receive a separate DR for every category of undefined behaviour to clarify that the same rules for undefined behaviour apply everywhere?
next prev parent reply other threads:[~2024-04-02 17:57 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 [this message] 2024-04-02 18:18 ` jsm28 at gcc dot gnu.org 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-TkqC6rFCuc@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).