Horton

Re: Tree-walker callbacks vs -Wdeprecated-non-prototype

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-09-19T04:53:30Z
Lists: pgsql-hackers 
Thomas Munro <thomas.munro@gmail.com> writes:
> On Mon, Sep 19, 2022 at 3:39 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I also note that our existing code in this area would break pretty
>> thoroughly on such a machine, so this isn't making it worse.

> Yeah, I don't expect it to be a practical problem on any real system
> (that is, I don't expect any real calling convention to transfer a
> struct T * argument in a different place than void *).  I just wanted
> to mention that it's a new liberty.

No, it's not, because the existing coding here is already assuming that.
The walker callbacks are generally declared as taking a "struct *"
second parameter, but expression_tree_walker et al think they are
passing a "void *" to them.  Even if a platform ABI had some weird
special rule about how to call functions that you don't know the
argument list for, it wouldn't fix this because the walkers sure do know
what their arguments are.  The only reason this code works today is that
in practice, "void *" *is* ABI-compatible with "struct *".

I'm not excited about creating a demonstrable opportunity for bugs
in order to make the code hypothetically more compatible with
hardware designs that are thirty years obsolete.  (Hypothetical
in the sense that there's little reason to believe there would
be no other problems.)

			regards, tom lane

Commits

  1. Remove accidentally added meson.build

  2. Disable clang 16's -Wcast-function-type-strict.

  3. Disable -Wdeprecated-non-prototype in the back branches.

  4. Revise tree-walk APIs to improve spec compliance & silence warnings.

  5. Future-proof the recursion inside ExecShutdownNode().