public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: Bernd Edlinger <bernd.edlinger@hotmail.de>,
	Jeff Law <law@redhat.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	Jason Merrill <jason@redhat.com>
Subject: Re: [PATCH] Add a warning for invalid function casts
Date: Wed, 11 Oct 2017 18:04:00 -0000	[thread overview]
Message-ID: <eebe6062-8326-19ed-1bd0-7214b3fad540@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1710111724350.9496@digraph.polyomino.org.uk>

On 10/11/2017 11:26 AM, Joseph Myers wrote:
> On Tue, 10 Oct 2017, Martin Sebor wrote:
>
>> The ideal solution for 1) would be a function pointer that can
>> never be used to call a function (i.e., the void* equivalent
>> for functions).[X]
>
> I don't think that's relevant.  The normal idiom for this in modern C
> code, if not just using void *, is void (*) (void), and since the warning
> is supposed to be avoiding excessive false positives and detecting the
> cases that are likely to be used for ABI-incompatible calls, the warning
> should allow void (*) (void) there.

I think we'll just have to agree to disagree.  I'm not convinced
that using void(*)(void) for this is idiomatic or pervasive enough
to drive design decisions.  Bernd mentioned just libgo and libffi
as the code bases that do, and both you and I have noted that any
pointer type works equally well for this purpose.  The problem
with almost any type, including void(*) (void), is that they can
be misused to call the incompatible function.  Since the sole
purpose of this new warning is to help find those misuses,
excluding void(*)(void) from the checking is directly at odds
with its goal.

I would prefer not to design an unnecessary back door into
the implementation and compromise the effectiveness of the warning
for what's clearly an inferior choice made without fully considering
the risk of misusing the result.  Instead I hope the warning will
drive improvements to code to make its intent explicit.  In my view
that's a good thing even if the code works correctly today.

I don't know how much code there is out that uses void (*)(void)
as a generic function pointer that's never intended to be called.
but I wouldn't expect there to be so much of it to make my
suggestion unfeasible.  I could of course be wrong.  If I am,
we'd find out pretty quickly.

But I've exhausted my arguments and so I think it's time for
me to bow out of the discussion.

Martin

  reply	other threads:[~2017-10-11 17:58 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-03 19:33 [RFA] " Bernd Edlinger
2017-10-03 21:34 ` Joseph Myers
2017-10-05 14:03   ` Bernd Edlinger
2017-10-05 14:10     ` Joseph Myers
2017-10-05  0:25 ` Eric Gallager
2017-10-05 13:39   ` Bernd Edlinger
2017-10-05 14:06     ` Andreas Schwab
2017-10-05 18:22     ` Eric Gallager
2017-10-05 16:16 ` Martin Sebor
2017-10-05 21:04   ` Bernd Edlinger
2017-10-05 21:47     ` Joseph Myers
2017-10-06 20:50       ` Jeff Law
2017-10-05 22:17     ` Martin Sebor
2017-10-06 13:26   ` Bernd Edlinger
2017-10-06 15:43     ` Martin Sebor
2017-10-06 18:25       ` Bernd Edlinger
2017-10-06 20:43         ` Martin Sebor
2017-10-06 21:01       ` Jeff Law
2017-10-06 22:23         ` Bernd Edlinger
2017-10-07 18:23           ` Bernd Edlinger
2017-10-09 16:48             ` Martin Sebor
2017-10-09 18:19               ` Bernd Edlinger
2017-10-09 18:46                 ` Martin Sebor
2017-10-09 22:33                   ` Bernd Edlinger
2017-10-10 15:35                     ` Martin Sebor
2017-10-10 16:55                       ` Joseph Myers
2017-10-10 17:39                         ` Martin Sebor
2017-10-10 23:57                           ` Joseph Myers
2017-10-11  3:52                             ` Martin Sebor
2017-10-11 17:28                               ` Joseph Myers
2017-10-11 18:04                                 ` Martin Sebor [this message]
2017-10-12 11:45                                   ` Pedro Alves
2017-10-12 11:52                               ` Pedro Alves
2017-10-12 11:59                               ` Pedro Alves
2017-10-12 15:26                                 ` Martin Sebor
2017-10-12 15:37                                   ` Joseph Myers
2017-10-21  9:54                     ` Bernd Edlinger
2017-11-03 21:47                     ` Joseph Myers
     [not found]                     ` <fa771535-8fcf-9b22-b5b9-eb928af5e817@hotmail.de>
2017-11-08 17:03                       ` [PING] " Bernd Edlinger
     [not found]                       ` <e64a07da-bada-893e-d1e4-bf4705cc1731@hotmail.de>
2017-11-15 20:52                         ` [PING**2] " Bernd Edlinger
2017-11-29 22:17                     ` Jason Merrill
2017-11-30 15:45                       ` [PATCHv2] " Bernd Edlinger
2017-11-30 15:56                         ` Jason Merrill
2017-11-30 16:22                           ` Bernd Edlinger
2017-11-30 17:32                             ` Jason Merrill
2017-11-30 18:06                               ` Bernd Edlinger
2017-11-30 18:19                                 ` Jason Merrill
2017-11-30 18:39                                   ` Bernd Edlinger
2017-11-30 18:39                                     ` Jason Merrill
2017-12-01 12:42                                       ` [PATCHv3] " Bernd Edlinger
2017-12-06 22:36                                         ` Jason Merrill
2017-12-07 20:48                                           ` Bernd Edlinger
2017-12-14 18:50                                             ` Jason Merrill
     [not found]                                           ` <1c3d1b9b-7a25-fae3-5c44-1a0efae77cc8@hotmail.de>
2017-12-14 18:35                                             ` Bernd Edlinger

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=eebe6062-8326-19ed-1bd0-7214b3fad540@gmail.com \
    --to=msebor@gmail.com \
    --cc=bernd.edlinger@hotmail.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=law@redhat.com \
    /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).