public inbox for [email protected]  

help / color / mirror / Atom feed

From: Thomas Munro <[email protected]>
To: Tom Lane <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Tree-walker callbacks vs -Wdeprecated-non-prototype
Date: Mon, 19 Sep 2022 16:32:59 +1200
Message-ID: <CA+hUKGL=dNzs7h85xq1UiHWVRU7+DYrqFkC4J4VZp_s2KD1dMA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CA+hUKGKpHPDTv67Y+s6yiC8KH5OXeDg6a-twWo_xznKTcG0kSA@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CA+hUKGK=xCw9_V7tCMvpT5D83AH8ArotTw3W4s70Vhqr7VgZkg@mail.gmail.com>
	<[email protected]>

On Mon, Sep 19, 2022 at 3:39 PM Tom Lane <[email protected]> wrote:
> Thomas Munro <[email protected]> writes:
> > On Mon, Sep 19, 2022 at 8:57 AM Tom Lane <[email protected]> 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.

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.  It's one thing to cast struct T *
to void * and back before dereferencing, and another to cast a pointer
to a function that takes struct T * to a pointer to a function that
takes void * and call it.  I considered proposing that myself when
first reporting this problem, but fear of language lawyers put me off.

view thread (19+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Tree-walker callbacks vs -Wdeprecated-non-prototype
  In-Reply-To: <CA+hUKGL=dNzs7h85xq1UiHWVRU7+DYrqFkC4J4VZp_s2KD1dMA@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox