Hi,
On 2019-06-25 17:25:12 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2019-06-25 16:15:17 -0400, Tom Lane wrote:
> >> One too many "consts" there. Pointer to const object seems fine.
> >> The other part is either meaningless or will cause problems.
>
> > Yea - I was thinking of the pointer in RelationData, where having it as
> > const *Routine const; would make sense (but it's annoying to do without
> > invoking technically undefined behaviour, doing ugly things with memcpy
> > or duplicating struct definitions).
>
> Yeah, I think trying to make such pointer fields "const", within
> structures that are otherwise not const, is just more trouble than it's
> worth. To start with, how will you assign the handler's output pointer
> to such a field?
Yea, it's annoying. C++ is slightly cleaner in this case, but it's still not
great. In most cases it's perfectly legal to cast the const away (that's
always legal) *and* write through that. The standard's requirement is
quite minimal - C99's 6.7.3 5) says:
If an attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-
const-qualified type, the behavior is undefined. ...
Which, in my reading, appears to mean that in the case of dynamically
allocated memory, the underlying memory can just be initialized ignoring
the constness. At least before the object is used via the struct, but
I'm not sure that strictly speaking matters.
In the case of relcache it's a bit more complicated, because we copy
over existing entries - but we don't ever actually change the constant
fields, even though they're part of a memcpy....
Greetings,
Andres Freund
