From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: jsonapi: scary new warnings with LTO enabled
In-reply-to: <0A3CF5C4-9947-42E3-89A9-34FCF7BA95BA@yesql.se>
References: <2074634.1744839761@sss.pgh.pa.us> <0A3CF5C4-9947-42E3-89A9-34FCF7BA95BA@yesql.se>
Comments: In-reply-to Daniel Gustafsson <daniel@yesql.se>
	message dated "Wed, 16 Apr 2025 23:52:42 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2078510.1744841564.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 16 Apr 2025 18:12:44 -0400
Message-ID: <2078511.1744841564@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2078511.1744841564%40sss.pgh.pa.us>
Precedence: bulk

Daniel Gustafsson <daniel@yesql.se> writes:
>> On 16 Apr 2025, at 23:42, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm not sure
>> how other than giving up on stack allocation of JsonLexContexts,
>> though, especially if we consider the jsonapi API frozen.  But seeing
>> that there are only three such call sites and none of them seem in the
>> least performance-critical, maybe we should just do that?

> I can't see any other option really, and there is no performance angle r=
eally
> so that should be safe.  Since I committed at least one of these, let me=
 know
> if you want me to tackle it.

The only alternative I can see that might stop the warning is if we
can find a way to make it clearer to the optimizer that the FREE()
isn't reached.  But I'm not sure about a trustworthy way to make that
happen.  Maybe it'd work to change the signature of freeJsonLexContext
(or perhaps better, add a separate entry point) so that the caller is
passing a bool constant that controls whether to free the struct.
We could have an Assert that compares that to the state of the
JSONLEX_FREE_STRUCT flag to catch mistakes.  This seems kind of messy
though.

			regards, tom lane