From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CDDDB3858407; Thu, 28 Mar 2024 22:51:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CDDDB3858407 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1711666309; bh=M4ey2GlqQO75VdXmuzi4wFemCaIDBHKaNqSR3vvdRpI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=En1synXRubLSmjovZMHq8JKHRNDpTHST+emlUbSyeHZHLMfuTO/T0oNFV7xPgS0qq +33a0kcqySNt0GoOnLOgngyMIILVbdQPVXrNwpT5VbH6O7/XjmyYq0apTiSMMfQWfU Djj8BVdcPYiEh9ciFhOWsNnzJrwCTRlFuE26UapA= From: "kkylheku at gmail dot com" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 7.1.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: kkylheku at gmail dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D83584 Kaz Kylheku changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kkylheku at gmail dot com --- Comment #22 from Kaz Kylheku --- (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 requir= ed 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.=20 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 ha= ve 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.=