From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Don't allocate IndexAmRoutine dynamically? |
Date: | 2019-06-25 21:53:47 |
Message-ID: | 29073.1561499627@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-06-25 17:25:12 -0400, Tom Lane wrote:
>> 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. ...
I'm not sure how you are parsing "the behavior is undefined" as "it's
legal". But in any case, I'm not on board with const-qualifying stuff
if we just have to cast the const away in common situations. I think
it'd be far more valuable to get to a state where cast-away-const can
be made an error.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-06-25 22:55:43 | Re: Don't allocate IndexAmRoutine dynamically? |
Previous Message | Andres Freund | 2019-06-25 21:42:52 | Re: Don't allocate IndexAmRoutine dynamically? |