Re: unconstify equivalent for volatile
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-02-22T20:31:39Z
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
Commits
-
Add macro to cast away volatile without allowing changes to underlying type
- 481018f28040 12.0 landed
-
Initialize structure at declaration
- 572e3e6634e5 12.0 landed