kernel: atomic: consistently use named type for atomic pointer values

[pabigot]

There's a typedef for non-pointer values compatible with atomic non-pointer objects. Add a similar typedef for pointer values, and the corresponding macro for initializing atomic pointer types.

This also will simplify replacing the Zephyr atomic API with one based on C11 atomics, should that be desirable. C11 atomic pointer values are not void *.

Pulled out of #28902 which is stalled based on review and consensus on what Zephyr's atomic API should do. See also #32170 (comment) and related issues.

[pabigot]

The compliance check failure is a false positive (no new typedefs).

[andyross]

This seems fine to me. Note that it's going to collide with some header rework in #32356 that splits up the atomic.h header across the variant backends, so one of us is going to have some rebase work to do.

[pabigot]

This seems fine to me. Note that it's going to collide with some header rework in #32356 that splits up the atomic.h header across the variant backends, so one of us is going to have some rebase work to do.

I wasn't aware of that. Any chance of a back-end that uses C11 API? I had one in progress, but reconciling the many implementations demotivated me.

I had thought to make use of this for a work-related bug in tcp, but couldn't because the pointer value I was going to use as the "in-use" flag is a pointer-to-function, which is not safely storable in a void *.

[ceolin]

This seems fine to me. Note that it's going to collide with some header rework in #32356 that splits up the atomic.h header across the variant backends, so one of us is going to have some rebase work to do.

I wasn't aware of that. Any chance of a back-end that uses C11 API? I had one in progress, but reconciling the many implementations demotivated me.

I had thought to make use of this for a work-related bug in tcp, but couldn't because the pointer value I was going to use as the "in-use" flag is a pointer-to-function, which is not safely storable in a void *.

Use C11 on Zephyr should not be discussed in a particular feature context IMHO. It impacts other areas like safety, toolchains, ... Technically speaking I'd love to be able use it, but ... as I mentioned it impacts other areas, MISRA-C, for instance, currently does not support C11, only C90 and C99. Also, there are C11 features that are optional, this can impact tooolchains compatibility (even assuming that they support C11).

[pabigot]

rebased on merged #32356