From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Tree-walker callbacks vs -Wdeprecated-non-prototype
In-reply-to: 
 <CA+hUKGK=xCw9_V7tCMvpT5D83AH8ArotTw3W4s70Vhqr7VgZkg@mail.gmail.com>
References: 
 <CA+hUKGKpHPDTv67Y+s6yiC8KH5OXeDg6a-twWo_xznKTcG0kSA@mail.gmail.com>
 <1725174.1651449765@sss.pgh.pa.us> <3953550.1663376882@sss.pgh.pa.us>
 <208054.1663534665@sss.pgh.pa.us>
 <CA+hUKGK=xCw9_V7tCMvpT5D83AH8ArotTw3W4s70Vhqr7VgZkg@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Mon, 19 Sep 2022 10:16:24 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <251835.1663558778.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 18 Sep 2022 23:39:38 -0400
Message-ID: <251836.1663558778@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/251836.1663558778%40sss.pgh.pa.us>
Precedence: bulk

Thomas Munro <thomas.munro@gmail.com> writes:
> On Mon, Sep 19, 2022 at 8:57 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ... 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

Well, what we're talking about is substituting "void *" (which is
required to be compatible with "char *") for a struct pointer type.
Standards legalese aside, that could only be a problem if the platform
ABI handles "char *" differently from struct pointer types.  The last
architecture I can remember dealing with where that might actually be
a thing was the PDP-10.  Everybody has learned better since then, but
the C committee is apparently still intent on making the world safe
for crappy machine architectures.

Also, if you want to argue that "void *" is not compatible with struct
pointer types, then it's not real clear to me that we aren't full of
other spec violations, because we sure do a lot of casting across that
(and even more with this patch as it stands).

I don't have the slightest hesitation about saying that if there's
still an architecture out there that's like that, we won't support it.
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.

			regards, tom lane