Hi, On 2020-06-30 10:15:05 -0400, Tom Lane wrote: > Peter Eisentraut <peter.eisentr...@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