From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: jsonapi: scary new warnings with LTO enabled |
Date: | 2025-04-16 22:12:44 |
Message-ID: | 2078511.1744841564@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> On 16 Apr 2025, at 23:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 really
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2025-04-16 22:17:34 | Re: jsonapi: scary new warnings with LTO enabled |
Previous Message | Daniel Gustafsson | 2025-04-16 21:52:42 | Re: jsonapi: scary new warnings with LTO enabled |