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/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really
Date: Thu, 28 Mar 2024 22:51:46 +0000	[thread overview]
Message-ID: <bug-83584-4-gvRsqcWVEW@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-83584-4@http.gcc.gnu.org/bugzilla/>

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

Kaz Kylheku <kkylheku at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kkylheku at gmail dot com

--- Comment #22 from Kaz Kylheku <kkylheku at gmail dot com> ---
(In reply to Pavel M from comment #21)
> FYI: Rationale for C, Revision 5.10, April-2003:
> > Even with an explicit cast, it is invalid to convert a function pointer to an object pointer or a pointer to void, or vice versa.

That means nothing; it's not even part of the standard document. In the
document itself, there are texts which are part of it, yet not "normative",
such as examples and footnotes.

The standard itself mentions the conversion as a common extension (not in a
normative way though, but at least in the document!)

Now the absence of a documented extension, it certainly isn't correct; it's
undefined behavior.

But it's not incorrect in a way that requires a diagnostic (when the required
cast is present).

The only diagnostic ever required when a pointer conversion is requested is
when the conversion isn't one of the ones allowed implicitly, and a correct
cast is missing.

The "absence of a documented extension" is irrelevant in the context of GCC,
which has the extension. That extension is at the cornerstone of the tech
stacks built on GCC, and required by POSIX.

It is not useful for the -pedantic option to pretend that GCC is some other
compiler which doesn't have any of its conforming extensions. 

Diagnostics like that could be useful to someone, but deserve their own
category, like -Wutmost-portability or something.

Someone who just wants the ISO-C-required situations diagnosed shouldn't have
to have these other diagnostics foisted on them.

You can always pick and choose diagnostics individually, but the categories are
useful, which is why they are there.

      parent reply	other threads:[~2024-03-28 22:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-83584-4@http.gcc.gnu.org/bugzilla/>
2018-01-01  0:15 ` joseph at codesourcery dot com
2022-01-12 19:22 ` pavel.morozkin at gmail dot com
2024-03-28 22:51 ` kkylheku at gmail dot com [this message]

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-83584-4-gvRsqcWVEW@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).