Re: DEREF_AFTER_NULL: src/common/jsonapi.c:2529 - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: DEREF_AFTER_NULL: src/common/jsonapi.c:2529
Date
Msg-id b389c5e5-e4af-45c2-bd51-59dcd358e1e4@eisentraut.org
Whole thread Raw
In response to Re: DEREF_AFTER_NULL: src/common/jsonapi.c:2529  (Jacob Champion <jacob.champion@enterprisedb.com>)
Responses Re: DEREF_AFTER_NULL: src/common/jsonapi.c:2529
List pgsql-hackers
On 07.04.26 00:01, Jacob Champion wrote:
>>> Or else make pfree() behave like free() [2] so that we don't
>>> have to have that particular papercut at all anymore?
>>
>> -many
>>
>> It's also not a path I want to add any unnecessary instructions to.
> 
> Okay, but I'd be curious to know how widespread this position is.

This was recently (as in: I still remember it) discussed:

https://www.postgresql.org/message-id/flat/cf26e970-8e92-59f1-247a-aa265235075b%40enterprisedb.com

Probably not worth opening up again.

But it seems to me that the pfree() in fe_memutils.c should 
Assert(pointer != NULL), to be consistent with the backend version.

I've also been thinking sometimes about a pfree_if_nonnull() (which 
would do { if (ptr) pfree(ptr)) }.  That would in some cases make the 
notation more compact and robust.  Maybe it could help here too?




pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Add pg_stat_autovacuum_priority
Next
From: Peter Geoghegan
Date:
Subject: Re: s/pg_attribute_always_inline/pg_always_inline/?