Re: Change pfree to accept NULL argument
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-08-22T18:30:22Z
Lists: pgsql-hackers
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: > Per discussion in [0], here is a patch set that allows pfree() to accept > a NULL argument, like free() does. So the question is, is this actually a good thing to do? If we were starting in a green field, I'd be fine with defining pfree(NULL) as okay. But we're not, so there are a couple of big objections: * Code developed to this standard will be unsafe to back-patch * The sheer number of places touched will create back-patching hazards. I'm not very convinced that the benefits of making pfree() more like free() are worth those costs. We could ameliorate the first objection if we wanted to back-patch 0002, I guess. (FWIW, no objection to your 0001. 0004 and 0005 seem okay too; they don't touch enough places to create much back-patching risk.) regards, tom lane
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