Re: Consistently use palloc_object() and palloc_array()

On Thu, Dec 04, 2025 at 10:31:41AM +0100, David Geier wrote:
> Attached are the two patches, rebased on latest master.
>
> The first one contains all changes that either result in no changes to
> the disassembly, or only in changes due to the line counts; because
> elog.h makes use of __LINE__.

Thanks. That's a lot to digest.

I have generated some reports by comparing builds of HEAD and
HEAD+0001 to indeed note that a lot of noise is caused by the line
number changes. And then, I have begun looking at contrib/ to start
with something as I had a bit of time today. One part which we need
to be careful about is that the allocations map with the actual
declarations, and I'm doubting my compiler to detect all of them, so
visual check for each path it is...

- void *out = palloc(sizeof(float4KEY));
+ void *out = palloc_object(float4KEY);

btree_gist/ has a bunch of these, which I guess don't really matter in
terms of type safety.

- sv = palloc(sizeof(bytea *) * (maxoff + 1));
+ sv = palloc_array(bytea *, (maxoff + 1));

This one also in gbt_var_picksplit(at)btree_utils_var(dot)c(dot) We have a
GBT_VARKEY.

+ keys = (char **) palloc_array(char *, key_count);
+ values = (char **) palloc_array(char *, val_count);

These two should not need casts.

- stack = palloc(sizeof(*stack));
+ stack = palloc_object(sepgsql_proc_stack);

This one in sepgsql was wrong, that can be detected with a compilation
of the module.

And done with the contrib/ part for the trival changes.
--
Michael