From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: unconstify equivalent for volatile |
Date: | 2019-02-18 16:32:00 |
Message-ID: | 20190218163200.slspmu3b7n45sskf@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-02-18 10:43:50 -0500, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> > I propose to add an equivalent to unconstify() for volatile. When
> > working on this, I picked the name unvolatize() mostly as a joke, but it
> > appears it's a real word. Other ideas?
>
> Umm ... wouldn't this amount to papering over actual bugs? I can
> think of legitimate reasons to cast away const, but casting away
> volatile seems pretty dangerous, and not something to encourage
> by making it notationally easy.
Most of those seem to be cases where volatile was just to make sigsetjmp
safe. There's plently legitimate cases where we need to cast volatile
away in those, e.g. because the variable needs to be passed to memcpy.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-02-18 16:36:50 | Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line |
Previous Message | Andres Freund | 2019-02-18 16:29:15 | Re: Use varargs macro for CACHEDEBUG |