|
Message-ID: <20170704211909.GR1627@brightrain.aerifal.cx> Date: Tue, 4 Jul 2017 17:19:09 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: more on missing volatile qualifications On Sun, Jun 25, 2017 at 01:06:29PM +0200, Jens Gustedt wrote: > Hello Szabolcs, > > On Sun, 25 Jun 2017 12:17:04 +0200 Szabolcs Nagy <nsz@...t70.net> wrote: > > > pthread_once_t and pthread_spinlock_t qualifiers are > > visible in the c++ name mangling if a c++ function takes > > pointer to them as arguments so the change is an abi break. > > too bad, so we can't change these two > > There is a reading of the C standard that says that volatile only has > implications if an object itself is such qualified, having a volatile > qualified lvalue access isn't enough. I don't think that any current > compiler does such weird things, but who knows where optimisers will > go in the future. Indeed. GCC seems committed to treating "accesses through volatile lvalue" as volatile, but I'd rather not depend on it. Perhaps we should add a primitive to atomic.h for loading the value of atomics so that we never access them directly; then volatile would not matter. > AFAICS for the third finding in sigaction.c this would not be an > issue. Since in addition this is something dealing with signal stuff, > I still think that volatile would be in order, here. The line: memcpy(set, handler_set, sizeof handler_set); is not valid if handler_set is made volatile; we'd have to write out the code to copy it. Not a big deal though, and more correct anyway; using memcpy to copy something that's semantically atomic is sloppy. Unfortunately since I don't want to encode knowledge of the naming of sigset_t internals here, we'd probably need a loop to copy to a non-volatile array the same as handler_set, then memcpy from there to set. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.