From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Dilger <hornschnorter(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Constifying numeric.c's local vars |
Date: | 2018-02-22 04:45:22 |
Message-ID: | 21221.1519274722@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
>> This means that the const variable 'const_zero' contains a pointer that is
>> non-const, pointing at something that is static const, stored in read only
>> memory. Yikes.
> I still believe this is unsafe.
I'm with Andres: I don't see the problem. It's true that we've casted
away a chance for the compiler to notice a problem, but that's not the
only defense against problems. If we did try to modify const_zero,
what should happen now is that we get a SIGSEGV from trying to scribble
on read-only memory. But that's actually a step forward from before.
Before, we'd have successfully modified the value of const_zero and
thereby silently bollixed subsequent computations using it. Since,
in fact, the code should never try to modify const_zero, the SIGSEGV
should never happen. So effectively we have a hardware-enforced Assert
that we don't modify it, and that seems good.
As far as compiler-detectable mistakes go, Andres' changes to declare
various function inputs as const seem like a pretty considerable
improvement too, even if they aren't offering 100% coverage.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2018-02-22 05:05:27 | Re: ALTER TABLE ADD COLUMN fast default |
Previous Message | Robert Haas | 2018-02-22 04:10:28 | Re: [HACKERS] Partition-wise aggregation/grouping |