Re: Change pfree to accept NULL argument
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-08-24T12:14:16Z
Lists: pgsql-hackers
On Wed, 24 Aug 2022 at 23:07, David Rowley <dgrowleyml@gmail.com> wrote: > One counter argument to that is for cases like list_free_deep(). > Right now if I'm not mistaken there's a bug (which I just noticed) in > list_free_private() that would trigger if you have a List of Lists and > one of the inner Lists is NIL. The code in list_free_private() just > seems to go off and pfree() whatever is stored in the element, which I > think would crash if it found a NIL List. If pfree() was to handle > NULLs at least that wouldn't have been a crash, but in reality, we > should probably fix that with recursion if we detect the element IsA > List type. If we don't use recursion, then the "free" does not seem > very "deep". (Or maybe it's too late to make it go deeper as it might > break existing code.) Hmm, that was a false alarm. It seems list_free_deep() can't really handle freeing sublists as the list elements might be non-Node types, which of course have no node tag, so we can't check for sub-Lists. David
Commits
-
Add more detail why repalloc and pfree do not accept NULL pointers
- 805a397db40b 16.0 landed
-
Remove unneeded null pointer checks before PQfreemem()
- e890ce7a4feb 16.0 landed
-
Remove unnecessary casts in free() and pfree()
- 45987aae260a 16.0 landed