Thread

Commits

Fix -Wcast-function-type warnings
- de8feb1f3a23 14.0 landed

warnings for invalid function casts

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2020-06-30T06:47:56Z

Some time ago, there were some discussions about gcc warnings produced 
by -Wcast-function-type [0].  To clarify, while that thread seemed to 
imply that the warnings appear by default in some compiler version, this 
is not the case AFAICT, and the warnings are entirely optional.

So I took a look at what it would take to fix all the warnings and came 
up with the attached patch.

There are three subplots:

1. Changing the return type of load_external_function() and 
lookup_external_function() from PGFunction to a generic pointer type, 
which is what the discussion in [0] started out about.

2. There is a bit of cheating in dynahash.c.  They keycopy field is 
declared as a function pointer that returns a pointer to the 
destination, to match the signature of memcpy(), but then we assign 
strlcpy() to it, which returns size_t.  Even though we never use the 
return value, I'm not sure whether this could break if size_t and 
pointers are of different sizes, which in turn is very unlikely.

3. Finally, there is some nonsense necessary in plpython, which is 
annoying but otherwise uninteresting.

Is there anything we want to pursue further here?


[0]: 
https://www.postgresql.org/message-id/flat/20180206200205.f5kvbyn6jawtzi6s%40alap3.anarazel.de

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: warnings for invalid function casts

Tom Lane <tgl@sss.pgh.pa.us> — 2020-06-30T14:15:05Z

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> There are three subplots:

> 1. Changing the return type of load_external_function() and 
> lookup_external_function() from PGFunction to a generic pointer type, 
> which is what the discussion in [0] started out about.

I feel like what you propose to do here is just shifting the problem
around: we're still casting from a function pointer that describes one
concrete call ABI to a function pointer that describes some other concrete
call ABI.  That is, "void (*ptr) (void)" is *not* disclaiming knowledge
of the function's signature, in the way that "void *ptr" disclaims
knowledge of what a data pointer points to.  So if current gcc fails to
warn about that, that's just a random and indeed obviously wrong decision
that they might change someday.

Re-reading the original discussion, it seems like what we have to do
if we want to suppress these warnings is to fully buy into POSIX's
assertion that casting between data and function pointers is OK:

    Note that conversion from a void * pointer to a function pointer as in:
    fptr = (int (*)(int)) dlsym(handle, "my_function");
    is not defined by the ISO C standard. This standard requires this
    conversion to work correctly on conforming implementations.

I suggest therefore that a logically cleaner solution is to keep the
result type of load_external_function et al as "void *", and have
callers cast that to the required specific function-pointer type,
thus avoiding ever casting between two function-pointer types.
(We could keep most of your patch as-is, but typedef GenericFunctionPtr
as "void *" not a function pointer, with some suitable commentary.)

> 2. There is a bit of cheating in dynahash.c.

It's slightly annoying that this fix introduces an extra layer of
function-call indirection.  Maybe that's not worth worrying about,
but I'm tempted to suggest that we could fix it on the same principle
with

	hashp->keycopy = (HashCopyFunc) (void *) strlcpy;

> 3. Finally, there is some nonsense necessary in plpython, which is 
> annoying but otherwise uninteresting.

Again, it seems pretty random to me that this suppresses any warnings,
but it'd be less so if the intermediate cast were to "void *".

			regards, tom lane

Re: warnings for invalid function casts

Andres Freund <andres@anarazel.de> — 2020-06-30T19:12:40Z

Hi,

On 2020-06-30 08:47:56 +0200, Peter Eisentraut wrote:
> Some time ago, there were some discussions about gcc warnings produced by
> -Wcast-function-type [0].  To clarify, while that thread seemed to imply
> that the warnings appear by default in some compiler version, this is not
> the case AFAICT, and the warnings are entirely optional.

Well, it's part of -Wextra. Which I think a fair number of people just
always enable...


> There are three subplots:
> 
> 1. Changing the return type of load_external_function() and
> lookup_external_function() from PGFunction to a generic pointer type, which
> is what the discussion in [0] started out about.

To a generic *function pointer type*, right?


> 2. There is a bit of cheating in dynahash.c.  They keycopy field is declared
> as a function pointer that returns a pointer to the destination, to match
> the signature of memcpy(), but then we assign strlcpy() to it, which returns
> size_t.  Even though we never use the return value, I'm not sure whether
> this could break if size_t and pointers are of different sizes, which in
> turn is very unlikely.

I agree that it's a low risk,


> Is there anything we want to pursue further here?

You mean whether we want to do further changes in the vein of yours, or
whether we want to apply your patch?

Greetings,

Andres Freund

Re: warnings for invalid function casts

Andres Freund <andres@anarazel.de> — 2020-06-30T19:21:35Z

Hi,

On 2020-06-30 10:15:05 -0400, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> > There are three subplots:
> 
> > 1. Changing the return type of load_external_function() and 
> > lookup_external_function() from PGFunction to a generic pointer type, 
> > which is what the discussion in [0] started out about.
> 
> I feel like what you propose to do here is just shifting the problem
> around: we're still casting from a function pointer that describes one
> concrete call ABI to a function pointer that describes some other concrete
> call ABI.  That is, "void (*ptr) (void)" is *not* disclaiming knowledge
> of the function's signature, in the way that "void *ptr" disclaims
> knowledge of what a data pointer points to.  So if current gcc fails to
> warn about that, that's just a random and indeed obviously wrong decision
> that they might change someday.

ISTM that it's unlikely that they'd warn about casting from one
signature to another? That'd basically mean that you're not allowed to
cast function pointers at all anymore? There's a legitimate reason to
distinguish between pointers to functions and pointers to data - but
what'd be the point in forbidding all casts between different function
pointer types?

> > 2. There is a bit of cheating in dynahash.c.
> 
> It's slightly annoying that this fix introduces an extra layer of
> function-call indirection.  Maybe that's not worth worrying about,
> but I'm tempted to suggest that we could fix it on the same principle
> with

Hm. At first I was going to say that every compiler worth its salt
should be able to optimize the indirection, but that's probably not
generally true, due to returning dest "manually". If the wrapper instead
just added explicit cast to the return type it'd presumably be ok.

Greetings,

Andres Freund

Re: warnings for invalid function casts

Tom Lane <tgl@sss.pgh.pa.us> — 2020-06-30T19:38:20Z

Andres Freund <andres@anarazel.de> writes:
> On 2020-06-30 10:15:05 -0400, Tom Lane wrote:
>> I feel like what you propose to do here is just shifting the problem
>> around: we're still casting from a function pointer that describes one
>> concrete call ABI to a function pointer that describes some other concrete
>> call ABI.  That is, "void (*ptr) (void)" is *not* disclaiming knowledge
>> of the function's signature, in the way that "void *ptr" disclaims
>> knowledge of what a data pointer points to.  So if current gcc fails to
>> warn about that, that's just a random and indeed obviously wrong decision
>> that they might change someday.

> ISTM that it's unlikely that they'd warn about casting from one
> signature to another?

Uh, what?  Isn't that *exactly* what this warning class does?
If it doesn't do that, what good is it?  I mean, I can definitely
see the point of warning when you cast a function pointer to some
other not-ABI-compatible function pointer type, because that might
be a mistake, just like assigning "int *" to "double *" might be.

gcc 8's manual says

'-Wcast-function-type'
     Warn when a function pointer is cast to an incompatible function
     pointer.  In a cast involving function types with a variable
     argument list only the types of initial arguments that are provided
     are considered.  Any parameter of pointer-type matches any other
     pointer-type.  Any benign differences in integral types are
     ignored, like 'int' vs.  'long' on ILP32 targets.  Likewise type
     qualifiers are ignored.  The function type 'void (*) (void)' is
     special and matches everything, which can be used to suppress this
     warning.  In a cast involving pointer to member types this warning
     warns whenever the type cast is changing the pointer to member
     type.  This warning is enabled by '-Wextra'.

so it seems like they've already mostly crippled the type-safety of the
warning with the provision about "all pointer types are interchangeable"
:-(.  But they certainly are warning about *some* cases of casting one
signature to another.

In any case, I think the issue here is what is the escape hatch for saying
that "I know this cast is okay, don't warn about it, thanks".  Treating
"void (*) (void)" as special for that purpose is nothing more nor less
than a kluge, so another compiler might do it differently.  Given the
POSIX restriction, I think we could reasonably use "void *" instead.

			regards, tom lane

Re: warnings for invalid function casts

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2020-07-03T14:04:10Z

On 2020-06-30 21:38, Tom Lane wrote:
> In any case, I think the issue here is what is the escape hatch for saying
> that "I know this cast is okay, don't warn about it, thanks".  Treating
> "void (*) (void)" as special for that purpose is nothing more nor less
> than a kluge, so another compiler might do it differently.  Given the
> POSIX restriction, I think we could reasonably use "void *" instead.

I think gcc had to pick some escape hatch that is valid also outside of 
POSIX, so they just had to pick something.  If we're disregarding 
support for these Harvard architecture type things, then we might as 
well use void * for easier notation.

Btw., one of the hunks in my patch was in PL/Python.  I have found an 
equivalent change in the core Python code, which does make use of void 
(*) (void): https://github.com/python/cpython/commit/62be74290aca

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: warnings for invalid function casts

Tom Lane <tgl@sss.pgh.pa.us> — 2020-07-03T14:40:00Z

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2020-06-30 21:38, Tom Lane wrote:
>> In any case, I think the issue here is what is the escape hatch for saying
>> that "I know this cast is okay, don't warn about it, thanks".  Treating
>> "void (*) (void)" as special for that purpose is nothing more nor less
>> than a kluge, so another compiler might do it differently.  Given the
>> POSIX restriction, I think we could reasonably use "void *" instead.

> I think gcc had to pick some escape hatch that is valid also outside of 
> POSIX, so they just had to pick something.  If we're disregarding 
> support for these Harvard architecture type things, then we might as 
> well use void * for easier notation.

As long as it's behind a typedef, the code will look the same in any
case ;-).

> Btw., one of the hunks in my patch was in PL/Python.  I have found an 
> equivalent change in the core Python code, which does make use of void 
> (*) (void): https://github.com/python/cpython/commit/62be74290aca

Given that gcc explicitly documents "void (*) (void)" as being what
to use, they're going to have a hard time changing their minds about
that ... and gcc is dominant enough in this space that I suppose
other compilers would have to be compatible with it.  So even though
it's theoretically bogus, I suppose we might as well go along with
it.  The typedef will allow a centralized fix if we ever find a
better answer.

			regards, tom lane

Re: warnings for invalid function casts

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2020-07-04T11:36:44Z

On 2020-07-03 16:40, Tom Lane wrote:
> Given that gcc explicitly documents "void (*) (void)" as being what
> to use, they're going to have a hard time changing their minds about
> that ... and gcc is dominant enough in this space that I suppose
> other compilers would have to be compatible with it.  So even though
> it's theoretically bogus, I suppose we might as well go along with
> it.  The typedef will allow a centralized fix if we ever find a
> better answer.

Do people prefer a typedef or just writing it out, like it's done in the 
Python code?

Attached is a provisional patch that has it written out.

I'm minimally in favor of that, since the Python code would be 
consistent with the Python core code, and the one other use is quite 
special and it might not be worth introducing a globally visible 
workaround for it.  But if we prefer a typedef then I'd propose 
GenericFuncPtr like in the initial patch.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: warnings for invalid function casts

Tom Lane <tgl@sss.pgh.pa.us> — 2020-07-04T14:16:07Z

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> Do people prefer a typedef or just writing it out, like it's done in the 
> Python code?

I'm for a typedef.  There is *nothing* readable about "(void (*) (void))",
and the fact that it's theoretically incorrect for the purpose doesn't
exactly aid intelligibility either.  With a typedef, not only are
the uses more readable but there's a place to put a comment explaining
that this is notionally wrong but it's what gcc specifies to use
to suppress thus-and-such warnings.

> But if we prefer a typedef then I'd propose 
> GenericFuncPtr like in the initial patch.

That name is OK by me.

			regards, tom lane

Re: warnings for invalid function casts

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2020-07-07T09:45:41Z

On 2020-07-04 16:16, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> Do people prefer a typedef or just writing it out, like it's done in the
>> Python code?
> 
> I'm for a typedef.  There is *nothing* readable about "(void (*) (void))",
> and the fact that it's theoretically incorrect for the purpose doesn't
> exactly aid intelligibility either.  With a typedef, not only are
> the uses more readable but there's a place to put a comment explaining
> that this is notionally wrong but it's what gcc specifies to use
> to suppress thus-and-such warnings.

Makes sense.  New patch here.

>> But if we prefer a typedef then I'd propose
>> GenericFuncPtr like in the initial patch.
> 
> That name is OK by me.

I changed that to pg_funcptr_t, to look a bit more like C and less like 
Java. ;-)

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: warnings for invalid function casts

Tom Lane <tgl@sss.pgh.pa.us> — 2020-07-07T16:08:15Z

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2020-07-04 16:16, Tom Lane wrote:
>> I'm for a typedef.  There is *nothing* readable about "(void (*) (void))",
>> and the fact that it's theoretically incorrect for the purpose doesn't
>> exactly aid intelligibility either.  With a typedef, not only are
>> the uses more readable but there's a place to put a comment explaining
>> that this is notionally wrong but it's what gcc specifies to use
>> to suppress thus-and-such warnings.

> Makes sense.  New patch here.

I don't have a compiler handy that emits these warnings, but this
passes an eyeball check.

>>> But if we prefer a typedef then I'd propose
>>> GenericFuncPtr like in the initial patch.

>> That name is OK by me.

> I changed that to pg_funcptr_t, to look a bit more like C and less like 
> Java. ;-)

I liked the first proposal better.  Not gonna fight about it though.

			regards, tom lane

Re: warnings for invalid function casts

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2020-07-14T18:58:28Z

On 2020-07-07 18:08, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> On 2020-07-04 16:16, Tom Lane wrote:
>>> I'm for a typedef.  There is *nothing* readable about "(void (*) (void))",
>>> and the fact that it's theoretically incorrect for the purpose doesn't
>>> exactly aid intelligibility either.  With a typedef, not only are
>>> the uses more readable but there's a place to put a comment explaining
>>> that this is notionally wrong but it's what gcc specifies to use
>>> to suppress thus-and-such warnings.
> 
>> Makes sense.  New patch here.
> 
> I don't have a compiler handy that emits these warnings, but this
> passes an eyeball check.

committed

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services