Re: [HACKERS] Constifying numeric.c's local vars - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Constifying numeric.c's local vars
Date
Msg-id 21221.1519274722@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Constifying numeric.c's local vars  (Mark Dilger <hornschnorter@gmail.com>)
List pgsql-hackers
Mark Dilger <hornschnorter@gmail.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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Partition-wise aggregation/grouping
Next
From: Andrew Dunstan
Date:
Subject: Re: ALTER TABLE ADD COLUMN fast default