Message-ID: <107eb23a-8ebb-42bc-99c0-ca551733e94e@proxel.se>
Date: Mon, 6 Apr 2026 13:59:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: DEREF_AFTER_NULL: src/common/jsonapi.c:2529
To: =?UTF-8?B?0JPQsNC70LrQuNC9INCh0LXRgNCz0LXQuQ==?= <galkin@rutoken.ru>,
 "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
References: <0b32e30f2fb94ae3b7f4ee15bbb072c0@rutoken.ru>
From: Andreas Karlsson <andreas@proxel.se>
Content-Language: en-US
In-Reply-To: <0b32e30f2fb94ae3b7f4ee15bbb072c0@rutoken.ru>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/107eb23a-8ebb-42bc-99c0-ca551733e94e%40proxel.se>
Precedence: bulk

On 4/6/26 10:26 AM, Галкин Сергей wrote:
> That seemed plausible to me, since there is a comment just above saying 
> that lex->errormsg can be NULL in shlib code. I also checked 
> PQExpBufferBroken(), and it does handle NULL, but that call is under 
> #ifdef, while the final access to lex->errormsg->data is unconditional.
> 
> I may be missing some invariant here, but it seems worth adding an 
> explicit NULL check. I prepared a corresponding patch and am attaching 
> it below in case you agree that this is a real issue.

The code is correct but a bit confusing. When JSONAPI_USE_PQEXPBUFFER is 
not defined jsonapi_makeStringInfo() will call palloc() which cannot 
return NULL so the NULL check (currently done by PQExpBufferBroken()) is 
only necessary when JSONAPI_USE_PQEXPBUFFER is defined.

If someone has a patch improving readability I would personally before 
merging this since this code feels more complex than it ideally should 
be but adding this noop NULL check to silence a false positive from a 
static analyzer does not seem like an improvement.

-- 
Andreas Karlsson
Percona