Change copyObject() to use typeof_unqual - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Change copyObject() to use typeof_unqual
Date
Msg-id 92f9750f-c7f6-42d8-9a4a-85a3cbe808f3@eisentraut.org
Whole thread Raw
Responses Re: Change copyObject() to use typeof_unqual
Re: Change copyObject() to use typeof_unqual
List pgsql-hackers
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 *.

(Even MSVC supports it, if we use a slightly newer version than is on 
CI.  For example, the new buildfarm member unicorn would support it.)

The second patch make some changes to take advantage of this improved 
qualifier handling.  EventTriggerCollectSimpleCommand() is a good 
example:  It takes a node tree and makes a copy that it keeps around for 
its internal purposes, but it can't communicate via its function 
signature that it promises not scribble on the passed node tree.  That 
is now fixed.

The obvious drawback is that if you use an older compiler that supports 
typeof but not typeof_unqual, this change will make you lose that check. 
  Currently, on the Cirrus CI system, only the NetBSD and OpenBSD tasks 
are affected by this.

Anyway, the reason I'm posting this now instead of, say, waiting another 
year, is that over in the thread "Make copyObject work in C++"[0], we're 
discussing, well, making copyObject() work in (standard) C++ (typeof and 
typeof_unqual are not in C++).  Assuming we want to make the 
typeof_unqual change in principle, I figured it would be worth 
considering doing that change first and then developing a C++ equivalent 
of that, instead of making a C++ equivalent of the current logic and 
then having to find another C++ solution when changing to typeof_unqual.


[0]: 
https://www.postgresql.org/message-id/flat/CAGECzQR21OnnKiZO_1rLWO0-16kg1JBxnVq-wymYW0-_1cUNtg@mail.gmail.com
Attachment

pgsql-hackers by date:

Previous
From: Zsolt Parragi
Date:
Subject: Re: Periodic authorization expiration checks using GoAway message
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Logical Replication of sequences