Re: DEREF_AFTER_NULL: src/common/jsonapi.c:2529
| От | Peter Eisentraut |
|---|---|
| Тема | Re: DEREF_AFTER_NULL: src/common/jsonapi.c:2529 |
| Дата | |
| Msg-id | b389c5e5-e4af-45c2-bd51-59dcd358e1e4@eisentraut.org обсуждение |
| Ответ на | Re: DEREF_AFTER_NULL: src/common/jsonapi.c:2529 (Jacob Champion <jacob.champion@enterprisedb.com>) |
| Ответы |
Re: DEREF_AFTER_NULL: src/common/jsonapi.c:2529
|
| Список | 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 по дате отправления: