Re: Consistently use palloc_object() and palloc_array()
David Geier <geidav.pg@gmail.com>
From: David Geier <geidav.pg@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Chao Li <li.evan.chao@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-11-28T21:47:08Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
btree_gist: Fix memory allocation formula
- 5cf03552fbb4 19 (unreleased) landed
-
Use palloc_object() and palloc_array(), the last change
- 4f7dacc5b82a 19 (unreleased) landed
-
pg_buffercache: Fix memory allocation formula
- 580b5c2f397f 18.2 landed
- 3f83de20ba2e 19 (unreleased) landed
-
Fix allocation formula in llvmjit_expr.c
- 0c67dbcc4e39 14.21 landed
- 07ddf6197b78 15.16 landed
- 5a4dc4aabd03 16.12 landed
- 0bab0c3b74af 17.8 landed
- 5b7bbf16db34 18.2 landed
- 06761b6096b6 19 (unreleased) landed
-
Use palloc_object() and palloc_array() in backend code
- 1b105f9472bd 19 (unreleased) landed
-
Use palloc_object() and palloc_array() in more areas of the tree
- 0c3c5c3b06a3 19 (unreleased) landed
-
Use more palloc_object() and palloc_array() in contrib/
- 31d3847a37be 19 (unreleased) landed
On 28.11.2025 22:28, Tom Lane wrote: > David Geier <geidav.pg@gmail.com> writes: >> On 27.11.2025 00:03, Chao Li wrote: >>> This is a large patch, I just take a quick look, and found that: >>> - *phoned_word = palloc(sizeof(char) * strlen(word) + 1); >>> + *phoned_word = palloc_array(char, strlen(word) + 1); >>> And >>> - params = (const char **) palloc(sizeof(char *)); >>> + params = palloc_object(const char *); >>> Applying palloc_array and palloc_object to char type doesn’t seem to improve anything. > >> You mean because sizeof(char) is always 1 and hence we could instead >> simply write: >> *phoned_word = palloc(strlen(word) + 1); >> params = palloc(1); >> I think the _array and _object variants are more expressive and for sure >> don't make the code less readable. > > Yeah, I agree these particular changes seem fine. When you're doing > address arithmetic for a memcpy or such, it may be fine to wire in an > assumption that sizeof(char) == 1, but I think doing that in other > contexts is not particularly good style. > > Another thing to note is that the proposed patch effectively changes > the expression evaluation order: > > - *phoned_word = palloc((sizeof(char) * strlen(word)) + 1); > + *phoned_word = palloc(sizeof(char) * (strlen(word) + 1)); > > Now, there's not actually any difference because sizeof(char) is 1, > but if it hypothetically weren't, the new version is likely more > correct. Presumably the +1 is meant to allow room for a trailing \0, > which is a char. Oh right. Good catch! > It'd be a good idea to review the patch to see if there are any > places where semantics are changed in a less benign fashion... I intentionally tried to avoid any semantic changes but it's of course possible something slipped through by accident. It's some ~1700 occurrences in the patch. If it takes ~10 seconds to check a single, it would take ~4.7h to review the entire patch. If no one is willing to take this on, I could split up the patch in 4 to 5 that each can be reviewed by someone else. -- David Geier