Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oa8mp-0007dL-0d for pgsql-hackers@arkaria.postgresql.org; Mon, 19 Sep 2022 04:53:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oa8mn-0006fd-C8 for pgsql-hackers@arkaria.postgresql.org; Mon, 19 Sep 2022 04:53:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oa8mn-0006fU-2q for pgsql-hackers@lists.postgresql.org; Mon, 19 Sep 2022 04:53:37 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oa8mj-0001Eb-2o for pgsql-hackers@postgresql.org; Mon, 19 Sep 2022 04:53:36 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 28J4rUkW259409; Mon, 19 Sep 2022 00:53:30 -0400 From: Tom Lane To: Thomas Munro cc: pgsql-hackers Subject: Re: Tree-walker callbacks vs -Wdeprecated-non-prototype In-reply-to: References: <1725174.1651449765@sss.pgh.pa.us> <3953550.1663376882@sss.pgh.pa.us> <208054.1663534665@sss.pgh.pa.us> <251836.1663558778@sss.pgh.pa.us> Comments: In-reply-to Thomas Munro message dated "Mon, 19 Sep 2022 16:32:59 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <259407.1663563210.1@sss.pgh.pa.us> Date: Mon, 19 Sep 2022 00:53:30 -0400 Message-ID: <259408.1663563210@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thomas Munro writes: > On Mon, Sep 19, 2022 at 3:39 PM Tom Lane 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