Commit
1e41ec3b07e4 ("Make temporary variable in _rcu_dereference
non-const") used the trick to add 0 to the pointer passed as a parameter
to the macro to get rid of its constness, should it be const (with the
end goal of avoiding compiler warnings). This is problematic (as shown
in [1]) if it is a pointer to an opaque type though, as the compiler
cannot perform pointer arithmetic on such a pointer (even though it
wouldn't really need to here, as we add 0).
Change it to use another trick to strip away the constness, that
shouldn't hit this problem. It was found in the same stackoverflow post
as the original trick [2]. It consists of using a statement expression
like so:
__typeof__(({ const int foo; foo; }))
The statement expression yields a value of type `int`. Statement
expressions are extensions to the C language, but we already use them
here.
[1] https://lists.lttng.org/pipermail/lttng-dev/2022-August/030247.html
[2] https://stackoverflow.com/a/
54016713
Change-Id: Ic73590ef4beaa1832161aa05a6df37e467f85116
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
/*
* If p is const (the pointer itself, not what it points to), using
* __typeof__(p) would declare a const variable, leading to
- * -Wincompatible-pointer-types errors. Using `+ 0` makes it an rvalue and
- * gets rid of the const-ness.
+ * -Wincompatible-pointer-types errors. Using the statement expression
+ * makes it an rvalue and gets rid of the const-ness.
*/
#ifdef __URCU_DEREFERENCE_USE_ATOMIC_CONSUME
# define _rcu_dereference(p) __extension__ ({ \
- __typeof__(p + 0) _________p1; \
+ __typeof__(__extension__ ({ \
+ __typeof__(p) _________p0 = { 0 }; \
+ _________p0; \
+ })) _________p1; \
__atomic_load(&(p), &_________p1, __ATOMIC_CONSUME); \
(_________p1); \
})