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: Wed, 03 Apr 2024 05:48:42 +0000 [thread overview] Message-ID: <bug-114526-4-1JvV8bjAp7@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 #19 from Kaz Kylheku <kkylheku at gmail dot com> --- (In reply to Harald van Dijk from comment #18) > (In reply to Kaz Kylheku from comment #17) > > The standrad does not define the conversion at the *type* level. > > ... > > The program is strictly conforming because it has no problem with type. > > The DRs I referenced include ones where type errors have explicitly been > stated not to render behaviour undefined. > > DR 132 (C90): > > /* No headers included */ > int checkup() > { > /* Case 1 */ > if (0) > printf("Printing.\n"); > /* Case 2 */ > return 2 || 1 / 0; > } > > Response: "The Response to Defect Report #109 addresses this issue. The > translation unit must be successfully translated." Note that this report response does not say that the translation unit must also be successfully linked, in a hosted implementation, to produce a program. > This, despite the fact that it implicitly declares as int(*)(), which is > incompatible with the type it is meant to be declared as. A mismatch, in linkage, can only occur when a reference is of a different type from the definition. In this translation unit alone, there is no type mismatch, because the unit contains only a reference to printf, and no definition. The translation unit can be part of a program where it makes sense. E.g. in a freestanding implementation, where there isn't a library with a printf, another translation unit can supply a compatible definition of printf. Then, if (0) can be flipped to if (1) and checkup() can be called, even. There is no type problem here whatsoever that is comparable to an operator being given operands whose type combination is not defined for the operator. That's a problem entirely confined in translation phase 7; it cannot be rescued by adding a suitable secondary translation unit. A call to an implicitly declared printf is translatable. There are requirements about every aspect of it. There are no requiremnts about how to translate (void *) &fn.
next prev parent reply other threads:[~2024-04-03 5:48 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 2024-04-02 21:37 ` harald at gigawatt dot nl 2024-04-03 5:48 ` kkylheku at gmail dot com [this message] 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-1JvV8bjAp7@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).