Jeehoon Kang

It seems C/C++ standard committee members tend to agree that all bit patterns are valid for `u32` and other unsigned integer types: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r4.html "For unsigned integer types, the bits of...

@stjepang To be very pedantic (sorry!), `u8` is special in that everything can be legally cast to an array of `u8` in Rust or `char` in C/C++. But `u32` is...

I believe (1) Rust should not blame padding bytes as `invalidate` values as well, and (2) we should de-deprecate `AtomicCell::get_mut()`. This idea is not just popping from my head, but...

According to C17 6.2.6p6, "padding bytes take unspecified values": > When a value is stored in an object of structure or union type, including in a member object, the bytes...

For unnamed members/paddings, I think the standard intentionally distinguished members and paddings: paddings are not members, and unnamed members are indeterminate and unnamed paddings are unspecified. Also, I think the...

- Unnamed fields are anonymous ones: https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html I still think paddings are not unnamed members mentioned in the standard. - I believe paddings are **never** indeterminate in C, so your...

- On "unnamed": I think distinguishing unnamed members and unnamed paddings, is the only way to make sense of C17 6.2.6p6 and [C17 6.7.1 p9 and 6.7.2.1 p15 + p17]...

Since MSRV = 1.36 now, we can use `AtomicU64` now: https://doc.rust-lang.org/std/sync/atomic/struct.AtomicU64.html

Very sad. Do you think it's worth it to use AtomicU64 for those platforms that support it? My opinion is yes, because, e.g., major 32-bit architectures support AtomicU64.

I agree with @stjepang on this issue. We can implement status trackers on top of scoped threads and other utilities, so I don't see much necessity for adding it as...