Thread: warnings for invalid function casts
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
Attachment
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
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
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
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
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
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
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
Attachment
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
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
Attachment
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
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