[cfe-dev] Const-ness of atomic_load parameter in C

[Richard Smith via cfe-dev]

On 29 May 2018 at 15:35, JF Bastien via cfe-dev <cfe-dev at lists.llvm.org>
wrote:

> Hi cfe-dev,
>
> C++11 onwards specs the non-member functions atomic_load and
> atomic_load_explicit as taking the atomic<T> by const (potentially
> volatile) pointer. C11, in its infinite wisdom, decided to drop the const,
> and C17 will fix this with DR459
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_459> (the
> current draft forgot to fix B.16, but that’s not the normative part).
>
> I suggest we allow passing const _Atomic(T)* in all versions of C. It
> seems silly to special-case C11’s semantics because they allow strictly
> less code to work. I’d usually just post these patches, but the
> not-quite-correct C11 semantics made me think twice.
>
> This doesn’t affect C++ (unless you try to use stdatomic.h in C++ which…
> you shouldn’t…).
>
> I would change the following (independently, they don’t need to
> synchronize-with):
>
>    - clang’s lib/Headers/stdatomic.h implements these as #define to the
>    __c11_* equivalent, which are builtins with custom typecheck. Fix the
>    typecheck.
>    - Additionally, libc++ defines the __c11_* functions in include/atomic
>    for the sake of GCC compatibility. Fix their declaration.
>
>
> It seems GCC already doesn’t require const: https://godbolt.org/g/4Q2vre
>
> Thoughts?
>

Your plan sounds fine to me. We generally apply DR resolutions
retroactively.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180529/3871597a/attachment.html>