warnings for invalid function casts

Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

warnings for invalid function casts

Peter Eisentraut-6
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

0001-Fix-Wcast-function-type-warnings.patch (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: warnings for invalid function casts

Tom Lane-2
Peter Eisentraut <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: warnings for invalid function casts

Andres Freund
In reply to this post by Peter Eisentraut-6
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


Reply | Threaded
Open this post in threaded view
|

Re: warnings for invalid function casts

Andres Freund
In reply to this post by Tom Lane-2
Hi,

On 2020-06-30 10:15:05 -0400, Tom Lane wrote:

> Peter Eisentraut <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: warnings for invalid function casts

Tom Lane-2
Andres Freund <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: warnings for invalid function casts

Peter Eisentraut-6
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


Reply | Threaded
Open this post in threaded view
|

Re: warnings for invalid function casts

Tom Lane-2
Peter Eisentraut <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: warnings for invalid function casts

Peter Eisentraut-6
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

v2-0001-Fix-Wcast-function-type-warnings.patch (13K) Download Attachment