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
