Documentation/atomic_t: Clarify signed vs unsigned
Clarify the whole signed vs unsigned issue for atomic_t. There has been enough confusion on this topic to warrant a few explicit words I feel. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>hifive-unleashed-5.2
parent
db467147f1
commit
f1887143f5
|
@ -56,6 +56,23 @@ Barriers:
|
||||||
smp_mb__{before,after}_atomic()
|
smp_mb__{before,after}_atomic()
|
||||||
|
|
||||||
|
|
||||||
|
TYPES (signed vs unsigned)
|
||||||
|
-----
|
||||||
|
|
||||||
|
While atomic_t, atomic_long_t and atomic64_t use int, long and s64
|
||||||
|
respectively (for hysterical raisins), the kernel uses -fno-strict-overflow
|
||||||
|
(which implies -fwrapv) and defines signed overflow to behave like
|
||||||
|
2s-complement.
|
||||||
|
|
||||||
|
Therefore, an explicitly unsigned variant of the atomic ops is strictly
|
||||||
|
unnecessary and we can simply cast, there is no UB.
|
||||||
|
|
||||||
|
There was a bug in UBSAN prior to GCC-8 that would generate UB warnings for
|
||||||
|
signed types.
|
||||||
|
|
||||||
|
With this we also conform to the C/C++ _Atomic behaviour and things like
|
||||||
|
P1236R1.
|
||||||
|
|
||||||
|
|
||||||
SEMANTICS
|
SEMANTICS
|
||||||
---------
|
---------
|
||||||
|
|
Loading…
Reference in New Issue