Re: unconstify equivalent for volatile

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: unconstify equivalent for volatile
Date: 2019-02-22 20:31:39
Message-ID: 20190222203139.wqwfzilh6gopjij6@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-02-22 12:38:35 +0100, Peter Eisentraut wrote:
> On 2019-02-19 18:02, Andres Freund wrote:
> > But even if we were to decide we'd want to keep a volatile in SetLatch()
> > - which I think really would only serve to hide bugs - that'd not mean
> > it's a good idea to keep it on all the other functions in latch.c.
>
> What is even the meaning of having a volatile Latch * argument on a
> function when the actual latch variable (MyLatch) isn't volatile? That
> would just enforce certain constraints on the compiler inside that
> function but not on the overall program, right?

Right. But we should ever look/write into the contents of a latch
outside of latch.c, so I don't think that'd really be a problem, even if
we relied on volatiles.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Regina Obe 2019-02-22 20:33:08 CTE Changes in PostgreSQL 12, can we have a GUC to get old behavior
Previous Message Pavel Stehule 2019-02-22 19:57:53 Re: proposal: variadic argument support for least, greatest function