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
