On 20.01.26 10:37, Peter Eisentraut wrote:
Currently, when the argument of copyObject() is const-qualified, the
return type is also, because the use of typeof carries over all the
qualifiers. This is incorrect, since the point of copyObject() is to
make a copy to mutate. But apparently no code ran into it.
The new implementation uses typeof_unqual, which drops the qualifiers,
making this work correctly.
typeof_unqual is standardized in C23, but all recent versions of all the
usual compilers support it even in non-C23 mode, at least as
__typeof_unqual__. We add a configure/meson test for typeof_unqual and
__typeof_unqual__ and use it if it's available, else we use the existing
fallback of just returning void *.
I committed this first part, but it ran into some trouble on the buildfarm:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=taipan&dt=2026-02-04%2008%3A39%3A34
The problem is that configure detected that gcc supports typeof_unqual,
but the clang used to produce the .bc files does not.
This seems to be a possible problem in general, if we do all these
configure checks with $CC, but then run $CLANG assuming all the results
hold.
My first attempt to fix this was to set CLANG='clang -std=gnu23' to
effectively put clang into approximately the same mode as gcc. This
fixes this particular issue but then later fails when compiling .bc
files for the test_cplusplus module:
clang -std=gnu23 -xc++ -Wno-ignored-attributes -O2 -I. -I.
-I../../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2
-flto=thin -emit-llvm -c -o test_cplusplusext.bc test_cplusplusext.cpp
error: invalid argument '-std=gnu23' not allowed with 'C++'
This might be another looming problem. Do we need to look up, say,
CLANGXX separately from CLANG?
Another attempt was to switch the order of the configure test to check
for __typeof_unqual__ before typeof_unqual. This works, but it seems
totally unprincipled.
Any thoughts?
(Btw., the buildfarm member description says gcc 13, but it's actually
using gcc 15.)
