On Mon, Sep 19, 2022 at 8:57 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > I think we ought to seriously consider the alternative of changing > nodeFuncs.c about like I have here, but not touching the walkers/mutators, > and silencing the resulting complaints about function type casting by > doing the equivalent of > > - return expression_tree_walker(node, cost_qual_eval_walker, > - (void *) context); > + return expression_tree_walker(node, > + (tree_walker_callback) > cost_qual_eval_walker, > + (void *) context); > > We could avoid touching all the call sites by turning > expression_tree_walker and friends into macro wrappers that incorporate > these casts. This is fairly annoying, in that it gives up the function > type safety the C committee wants to impose on us; but I really think > the data type safety that we're giving up in this version of the patch > is a worse hazard.
But is it defined behaviour? https://stackoverflow.com/questions/559581/casting-a-function-pointer-to-another-type > BTW, I was distressed to discover that someone decided they could > use ExecShutdownNode as a planstate_tree_walker() walker even though > its argument list is not even the right length. I'm a bit flabbergasted > that we seem to have gotten away with that so far, because I'd have > thought for sure that it'd break some platform's convention for which > argument gets passed where. I think we need to fix that, independently > of what we do about the larger scope of these problems. To avoid an > API break, I propose making ExecShutdownNode just be a one-liner that > calls an internal ExecShutdownNode_walker() function. (I've not done > it that way in the attached, though.) Huh... wouldn't systems that pass arguments right-to-left on the stack receive NULL for node? That'd include the SysV i386 convention used on Linux, *BSD etc. But that can't be right or we'd know about it... But certainly +1 for fixing that regardless.
