C17 is only a “bugfix” release of the C standard, with one exception, the changes concerning ATOMIC_VAR_INIT
are a normative.
In C11, ATOMIC_VAR_INIT
had to be used as an initializer for an atomic object. Several defect reports remarked that the working of this was not clear at all.
- The default initialization of atomic objects, such as static variables was not clear.
ATOMIC_VAR_INIT
was specified to receive a value as its argument. But not forstruct
there are no constant values that could be uniformly used in file scope.
When discussing these problems, the committee noted that all known implementations of C11 atomics did not need the macro for an initialization. Standard initializers just as for any other data type could be used. It was thus decided to remove the obligation to use the macro for an initialization. Section 7.17.2 p2, second sentence now reads:
An atomic object with automatic storage duration that is not explicitly initialized using ATOMIC_VAR_INIT is initially in an indeterminate state; however, the default (zero) initialization for objects with static or thread-local storage duration is guaranteed to produce a valid state.
By that small change atomic variables are not treated any different from other variables anymore. If they are explicitly or implicitly initialized they have a well defined state. Also since now atomic variables are like anybody else, the initial value in case of default initialization is 0
.
Because now the macro is basically useless, a note was added to 7.31.8, future library directions for stdatomic.h
:
The macro
ATOMIC_VAR_INIT
is an obsolescent feature.
Is there a reason you use C17 instead of C18?
I personally prefer C18 because it’s less confusable with C++17 than C17.
We closed this in 2017 and the version macro refers to that year. ISO needed another 6 month or so, but that is just their artificial procedure.