mirror of
https://github.com/FEX-Emu/linux.git
synced 2024-12-14 21:01:29 +00:00
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>
This commit is contained in:
parent
db467147f1
commit
f1887143f5
@ -56,6 +56,23 @@ Barriers:
|
||||
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
|
||||
---------
|
||||
|
Loading…
Reference in New Issue
Block a user