Feedback-ID: id4a34324:Fastmail
Date: Mon, 6 Apr 2026 14:46:14 -0400
From: Andres Freund <andres@anarazel.de>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Andreas Karlsson <andreas@proxel.se>,
	=?utf-8?B?0JPQsNC70LrQuNC9INCh0LXRgNCz0LXQuQ==?= <galkin@rutoken.ru>,
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Subject: Re: DEREF_AFTER_NULL: src/common/jsonapi.c:2529
Message-ID: <leyiwkml7kyrdxwjzhcmmi6rtyxxwofokfxhlkpbagfprmbqw2@jxdckvomcmug>
References: <0b32e30f2fb94ae3b7f4ee15bbb072c0@rutoken.ru>
 <107eb23a-8ebb-42bc-99c0-ca551733e94e@proxel.se>
 <CAOYmi+muy=Wtk0dv6J5HmcFTMvrPMe2MGN2X+hjZL7DKSUEXLQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAOYmi+muy=Wtk0dv6J5HmcFTMvrPMe2MGN2X+hjZL7DKSUEXLQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/leyiwkml7kyrdxwjzhcmmi6rtyxxwofokfxhlkpbagfprmbqw2%40jxdckvomcmug>
Precedence: bulk

Hi,

On 2026-04-06 10:57:22 -0700, Jacob Champion wrote:
> On Mon, Apr 6, 2026 at 4:59 AM Andreas Karlsson <andreas@proxel.se> wrote:
> > The code is correct but a bit confusing.
> 
> Yeah, it's not great. The need for this (security-critical!) code to
> wrangle three separate allocation conventions is error-prone, to say
> the least.

Indeed, that's quite terrible.

I guess getting rid of the stringinfo/pqexpbuffer split is not that easy, but
at least the common memory allocation stuff seems like it should be doable to
put through through the same wrappers for both FE/BE, handling whether we want
to error out or not by passing MCXT_ALLOC_NO_OOM or not.

That would require something like pstrdup_extended() to be added to both FE &
BE, but that seems doable?

I don't understand why that code needs stuff like

/*
 * Backend pfree() doesn't handle NULL pointers like the frontend's does; smooth
 * that over to reduce mental gymnastics. Avoid multiple evaluation of the macro
 * argument to avoid future hair-pulling.
 */
#define FREE(s) do {	\
	void *__v = (s);	\
	if (__v)			\
		pfree(__v);		\
} while (0)

How is the only sane answer here not to avoid ever freeing NULLs?
Particularly because this code started out as backend code. Yea, yea, we
probably didn't have NULLs due to erroring out on allocation failure, but
still.

Kinda seems like the fe_memutils.c pfree() should assert that the argument is
not null.


> > adding this noop NULL check to silence a false positive from a
> > static analyzer does not seem like an improvement.
> 
> We do occasionally merge code to silence false positives, and we could
> maybe do something with pg_assume() here, but I agree that it'd be
> better to refactor it so that it's obviously correct.

FWIW, it can be silenced by marking makeStringInfoExt() with
__attribute__((returns_nonnull)). Whether that's worth doing is a different
question.


Greetings,

Andres Freund