new warnings with clang-21 / how const is Datum

clang-21 shows some new warnings:

../src/backend/access/common/toast_internals.c:296:33: error: variable
'chunk_data' is uninitialized when passed as a const pointer argument
here [-Werror,-Wuninitialized-const-pointer]
296 | t_values[2] = PointerGetDatum(&chunk_data);

../src/backend/access/gist/gistutil.c:207:28: error: variable 'attrsize'
is uninitialized when passed as a const pointer argument here
[-Werror,-Wuninitialized-const-pointer]
207 |
PointerGetDatum(&attrsize));
|
^~~~~~~~
../src/backend/access/gist/gistutil.c:276:27: error: variable 'dstsize'
is uninitialized when passed as a const pointer argument here
[-Werror,-Wuninitialized-const-pointer]
276 |
PointerGetDatum(&dstsize));
|
^~~~~~~

The first one is easily fixed by re-arranging the code a bit.

The other two indicate more fundamental problems. The gist API uses
these arguments to pass back information; these pointers do not in fact
point to a const object.

This possibly means that the change

commit c8b2ef05f48
Author: Peter Eisentraut <peter(at)eisentraut(dot)org>
Date: Tue Sep 27 20:47:07 2022

Convert *GetDatum() and DatumGet*() macros to inline functions

that made PointerGetDatum() look like

static inline Datum
PointerGetDatum(const void *X)

was mistaken in adding the const qualifier.

We could remove that qualifier (this would propagate to several other
functions built on top of PointerGetDatum()), but then there will be
complaints from the other side:

static const TableAmRoutine heapam_methods = {

PG_RETURN_POINTER(&heapam_methods);

Then the question is, which one of these should be considered the outlier?

We could remove the const qualifications from the API and stick an
unconstify() around &heapam_methods.

Or we could maybe make a new function PointerNonConstGetDatum() that we
use for exceptional cases like the gist API.

There is a related issue that I have been researching for some time. It
seems intuitively correct that the string passed into a data type input
function should not be modified by that function. And so the relevant
functions could use const qualifiers like

extern Datum InputFunctionCall(FmgrInfo *flinfo, const char *str, ...);

which they currently do not.

There are a some places in the code where const strings get passed into
some *InputFunctionCall() functions and have their const qualifications
rudely cast away, which seems unsatisfactory.

Overall, the question to what extent fmgr functions are allowed to
modify objects pointed to by their input arguments doesn't seem to be
addressed anywhere.