Re: more on missing volatile qualifications

[Rich Felker <dalias@libc.org>]

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@port70.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