MIME-Version: 1.0
References: <2074634.1744839761@sss.pgh.pa.us>
 <0A3CF5C4-9947-42E3-89A9-34FCF7BA95BA@yesql.se>
 <2078511.1744841564@sss.pgh.pa.us>
 <DCD56158-A642-4954-87FF-9DAD5425F3FF@yesql.se>
 <2084687.1744844690@sss.pgh.pa.us>
 <CAOYmi+n+DHpaEV5hymhufutTgc+S=+pDQfXEUi4hMAV1eO8aTw@mail.gmail.com>
 <2087556.1744846124@sss.pgh.pa.us>
 <0A596D8B-24F3-408F-B89B-B42014B00A05@yesql.se>
 <2202326.1744903233@sss.pgh.pa.us>
 <CAOYmi+mxjW0GhSGPKoOy3TYrFcdTM=5FcUn=u1i7CFhb2303Zg@mail.gmail.com>
 <25801148-284F-41F9-A279-A4CF92623C77@yesql.se>
 <CAOYmi+=w3Q-3F=LCr9hPRhiG2HGv6sogGOJW3v9pwpoCD6wN+w@mail.gmail.com>
 <E4E01D53-5E8C-4D93-85A8-633E93D0A194@yesql.se>
 <CAOYmi+k+Cv4PrD9HWRh2gzZLweKK+375hBV0-N4Q9Zzb5PM24w@mail.gmail.com>
 <102E1997-FB99-4091-926C-9A8BB3EA168E@yesql.se>
In-Reply-To: <102E1997-FB99-4091-926C-9A8BB3EA168E@yesql.se>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Mon, 21 Apr 2025 11:58:34 -0700
Message-ID: 
 <CAOYmi+n7eShndhpJAZ-6+9h012nZfmuQbnj-p-L=ZnX96-PGVA@mail.gmail.com>
Subject: Re: jsonapi: scary new warnings with LTO enabled
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
	PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAOYmi%2Bn7eShndhpJAZ-6%2B9h012nZfmuQbnj-p-L%3DZnX96-PGVA%40mail.gmail.com>
Precedence: bulk

On Mon, Apr 21, 2025 at 11:46=E2=80=AFAM Daniel Gustafsson <daniel@yesql.se=
> wrote:
> We do, but with the current coding we call setJsonLexContextOwnsTokens
> immediately after creation which derefences the pointer without checkinf =
for
> allocation failure.

Right. (The flag does nothing on the OOM sentinel.)

> This means we dereference the pointer before we can check
> for an OOM return from pg_parse_json which even if safe seems to violate =
code
> readability no?

Personally, I'm fine with can't-fail APIs, as long as they're
documented as such. (I think the deferred error API was probably
chosen so that src/common JSON clients could be written without a lot
of pain?)

--Jacob