public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
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 19:41:52 +0000 [thread overview] Message-ID: <bug-114526-4-snNSdZwv11@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 #17 from Kaz Kylheku <kkylheku at gmail dot com> --- (In reply to Harald van Dijk from comment #14) > (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. The standrad does not define the conversion at the *type* level. > > > 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 program is strictly conforming because it has no problem with type. The language defines a division operator for the types int x int -> int. There can be divisions written x / y where we don't know that y is zero until a run-time input is supplied. The expression 1/0 has a meaning and is translatable; just the operand values are bad. Compilers have to be careful when doing constant folding not to blow up on bad expressions that are not actually called. Something like this could occur: switch (sizeof (T)) { case 4: ... 1 / (8 - sizeof (T)); case 8 ... 1 / (16 - sizeof (T)); } where if the size is 8, then case 4: never taken in that case, has a constant division by zero. Evaluation of constants is required for dead-code elimination, so dead code elimination cannot be counted on to remove bad expressions. But: (void *) &function has no meaning at all due to a type problem. Because it's a type problem, it is a static problem which speaks to the ability to translate the expression. That ability is not required. The standard is mum about converting a function pointer type to void * type, regardless of the specific run-time values involved. We wouldn't say that void f(void) { "abc" / "def"; } is strictly conforming because f is not called in the program. There is a type problem. Now in this case there is a constraint violation: it requires a diagnostic. (void *) &function has a problem in the same category: operator not defined for the given types. The only difference is that there is no requirement for a diagnostic. The implementation is justified in aborting the translation. Possibly with a diagnostic (which could say "conversion of function pointers to data pointers is not supported, goodbye!"). In summary, (void *) &function is a type mismatch error, which is not caught by the C type system due to there being no constraint violation. It's a hole in the type system. When an implementation hits a situation that triggers a hole in the type system, it is allowed to diagnose it and reject the program. Anyway, this is all moot because this bugzilla is about GNU C, which has the extension. The behavior is locally defined. We would like NOT to have a diagnostic under -Wpedantic, so we are on the same page. Whether your program is strictly conforming or not, we would like not to have it diagnosed under the -Wpedantic umbrella, and even if it is changed to a program which calls f. There is nothing wrong with the diagnostic, but it should be uncoupled from -Wpedantic and available under its own option. Possibly, an umbrella option could exist for this kind of "super pedantic" errors, like -Wconforming-extensions (warn about the use of GNU extensions that are conforming, and thus require no diagnostic by ISO C).
next prev parent reply other threads:[~2024-04-02 19:41 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 2024-04-02 19:41 ` kkylheku at gmail dot com [this message] 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-snNSdZwv11@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).