Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170625130629.03dc67bc@inria.fr>
Date: Sun, 25 Jun 2017 13:06:29 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: more on missing volatile qualifications

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.

> > Also, I can't think of any semantics for the three, where
> > opitimizing out loads or stores makes any sense, so this also
> > should never see any kind of performance regression.  
> 
> there was a case in glibc when volatile caused problems:
> some generic atomic macro tried to create a temporary using
> 
>   __typeof(*(p)) __tmp = *(p);
> 
> but then __tmp become volatile and operations on it generated
> useless load/stores to the stack. it could be worked around as
> 
>   __typeof( (__typeof(*(p))) *(p) ) __tmp = *(p);
> 
> is not volatile because the cast expression is unqualified.
> (musl does not have such __typeof hacks, but it is an
> example where volatile caused unexpeced regression)

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.

Thanks
Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

Content of type "application/pgp-signature" skipped

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.