3

sig_atomic_t is a typedef of int. But I am curious do we have an atomic type which is matched to uint32_t ?

damingzi
  • 676
  • 10
  • 28
  • It might be that your system has no 32-bit types *at all*. Like if it is a [36-bit computer](https://stackoverflow.com/a/6972551/597607), – Bo Persson Apr 04 '18 at 23:55
  • 3
    Note that `sig_atomic_t` is different from the types in ``. It does not provide inter-thread synchronization and the only guarantee is that it's an indivisible type. Often used in combination with `volatile` – LWimsey Apr 05 '18 at 00:19

3 Answers3

4

C11 defines following typedefs to atomic types in <stdatomic.h>:

atomic_bool
atomic_char
atomic_schar
atomic_uchar
atomic_short
atomic_ushort
atomic_int
atomic_uint
atomic_long
atomic_ulong
atomic_llong
atomic_ullong
atomic_char16_t
atomic_char32_t
atomic_wchar_t
atomic_int_least8_t
atomic_uint_least8_t
atomic_int_least16_t
atomic_uint_least16_t
atomic_int_least32_t
atomic_uint_least32_t
atomic_int_least64_t
atomic_uint_least64_t
atomic_int_fast8_t
atomic_uint_fast8_t
atomic_int_fast16_t
atomic_uint_fast16_t
atomic_int_fast32_t
atomic_uint_fast32_t
atomic_int_fast64_t
atomic_uint_fast64_t
atomic_intptr_t
atomic_uintptr_t
atomic_size_t
atomic_ptrdiff_t
atomic_intmax_t
atomic_uintmax_t

There is no atomic_uint32_t, so your options are:

  • You can use _Atomic(uint32_t) directly.
  • You can use one of existing alternative types (atomic_uint_least32_t, atomic_uint_fast32_t or even atomic_char32_t) if this fits your purpose (probably it doesn't).
  • You can assume atomic_uint is 32-bit and use it as a replacement. This should be actually one of the most portable ways as most OS (*BSDs, Linux, Windows) assume int is a 32-bit type.
  • but I didn't find stdatomic.h packaged in my gcc. Which gcc version has it? – damingzi Apr 09 '18 at 18:18
  • @damingzi I don't know when it first appeared, but GCC 7.3 has it. –  Apr 09 '18 at 18:43
  • "You can assume atomic_uint is 32-bit and use it as a replacement" -- no, you can't. That's the whole point of `uint32_t`. – Jason S Jul 12 '20 at 17:56
  • @JasonS Yes you can. In many cases `uint32_t` is `unsigned` and this is mandated by your platform. –  Jul 12 '20 at 19:59
  • I work on embedded processors. We cannot make such assumptions. – Jason S Jul 13 '20 at 17:51
  • As a practical matter, you may be able to anyway as long as you assert that it is the case and are grateful when the assertion fails because that loud obvious immediate failure gave you a chance to respond before having to debug anything. – Integer Poet Aug 22 '21 at 19:29
  • Blindly assuming `int` is 32-bit is plain wrong. Don't do that ever. It has always been 16-bits *minimum*. If you need 32-bits use `long` or one of the fixed size types. – Kevin Thibedeau Sep 20 '22 at 19:43
  • @KevinThibedeau You don't have to do it blindly. POSIX has always guaranteed `int` to be at least 32-bit. In the end, contrary to popular misconception, C standard _does not define your environment_ - your OS has the final say in that. Which is why some implementations use 8-bit `int` (GCC on AVR with `-mint8`), even though `int` is "16-bits minimum". –  Sep 21 '22 at 15:57
1

The standard does not define atomic types with exact sizes since a platform may not be able to handle exact sizes atomically. Even though a system has the type uint32_t, it may not be able to handle operations with that type atomically but maybe only with the type uint64_t, that's why there is only uint_least32_t, which guarantees you a type that for sure has 32 bits available but that could be mapped to uint64_t as well if a platform requires that for atomic operations.

The standard does allow you to use _Atomic(uint32_t) but even in that case it does not guarantee that this results in a type that has exactly 32 bits but instead the compiler is free to map that to the type that's nearest to the requested type and does allow atomic operations, which, again, could be uint64_t on some platform.

Note that the C standard itself never guarantees the existence of exact types, like uint32_t. Those types are optional to begin with. Only the POSIX standard requires those exact types to exist, yet the POSIX standard does not require them to be atomic.

Mecki
  • 125,244
  • 33
  • 244
  • 253
0

Ivan's answer is great (I hope you accept his, not this one), but it's worth mentioning that some compilers (I'm looking at you, MSVC) don't support C11 atomics.

If you're not concerned with such compilers, use C11 atomics.

If, OTOH, you need a bit portability, you may want to take a look at the atomic module in Portable Snippets (disclaimer: it's one of my projects, so take this suggestion with a grain of salt). There is no unsigned 32-bit atomic, but there are 32- and 64-bit signed atomic types which work well with a lot of compilers, including old (pre-C11) GCC, clang, and ICC, as well as suncc, ARM, and a few others.

nemequ
  • 16,623
  • 1
  • 43
  • 62