apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Nairn" <steven.na...@googlemail.com>
Subject apr_atomic_casptr() and apr_atomic_xchgptr()
Date Tue, 21 Aug 2007 08:22:33 GMT

while trying to compile a recent snapshot of APR
(apr_20070820101606.tar.gz) I came across a problem with
apr_atomic_xchgptr() in atomic/unix/mutex.c. On linux (Fedora Core
with GCC 4.1.1) it manifests as the warnings:
atomic/unix/mutex.c: In function 'apr_atomic_xchgptr':
atomic/unix/mutex.c:195: warning: passing argument 1 of 'mutex_hash'
from incompatible pointer type
atomic/unix/mutex.c:197: warning: assignment discards qualifiers from
pointer target type
Unfortunately on the system I'm using (iSeries, using ILE C) the
compiler is a bit more picky and counts these as errors, so I had a
bit of a closer look.

The first thing that confused me is the type of "mem" parameter to
apr_atomic_casptr() and apr_atomic_xchgptr(). All the other
apr_atomic_* functions take a pointer to a volatile value (an
apr_uint32_t) and it is the volatile value that is changed. However,
the apr_atomic_{cas,xchg}ptr functions take a pointer to a pointer to
a volatile value (void) and it is the (non-volatile) pointer to
volatile void that is changed. This seems a bit wrong to me - surely
since the functions do not dereference the pointer to volatile void
then the volatility of what it points to is academic? Also, since it
is the pointer to volatile void that is being changed by the functions
then shouldn't that pointer be marked volatile? That is, wouldn't it
make more sense to declare the "mem" parameter as "void * volatile *"
(pointer to volatile pointer to void) rather than "volatile void **"?

If this is done and the "mem" parameter to mutex_hash() changed to a
"volatile void *" then apr_atomic_xchgptr() compiles with no problems.
Also, the cast of "mem" to "void **" can be removed from

The second thing that confused me is that in apr_atomic_casptr() the
value of "* mem" is used to calculate the hash to find the mutex to
use. Everything else uses the value of "mem" (including
apr_atomic_xchgptr()). It makes sense to me that it should use the
address of the value it is changing (that is, "mem") rather than the
actual value that is being changed. Or am I way off beam?

I've had a look through bugzilla (42806) and saw that the volatile
qualifiers are likely to go away at some point (so this message is a
little pointless :-). Also from that bug I see that removing (and
therefore presumably moving) volatile qualifiers is seen as an ABI
break so apr_atomic_casptr() could not be changed. However,
apr_atomic_xchgptr() is a new function that isn't in 1.2.9 so that
could be changed. Am I barking up the wrong tree or should I post a
patch (or open a bug in bugzilla)?


View raw message