ATOMIC_VAR_INIT(3) says that in order to use functions atomic_xx '#include <stdatomic.h>' is needed. However, this include fails: > In file included from test-stdatomic.cpp:3: > /usr/include/stdatomic.h:186:17: error: unknown type name '_Bool' > typedef _Atomic(_Bool) atomic_bool; ^
For default-constructible base types, corresponding atomic template specializations in C++ provides constructors that make use of ATOMIC_VAR_INIT() excessive (and the macro is not defined in C++ AFAIR). In fact, use of stdatomic.h in C++ is undefined, it is not listed as part of the supported C library headers. So the best advice there is to use <atomic> as intended by C++. Still, I think this small wart you noted can be covered. See
.. see https://reviews.freebsd.org/D34686
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=c1a24b9dbeade11bfeedc91996672582f6ea32f2 commit c1a24b9dbeade11bfeedc91996672582f6ea32f2 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2022-03-27 21:16:15 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2022-03-28 00:16:02 +0000 sys/stdatomic.h: be nicer to c++ Use of stdatomic.h is undefined in C++, even the C++ 2020 standard does not list stdatomic.h as a C library header supported by the language. More, there are some subtle differences between the <atomic> C++ header, and C11+ stdatomic.h provided features. Nonetheless, it is a quality of the implementation aspect, so let mis-users mis-use stdatomic.h as they want, by making a compat shim for _Bool. PR: 262683 Reported by: yuri Reviewed by: dim, emaste Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D34686 sys/sys/stdatomic.h | 10 ++++++++++ 1 file changed, 10 insertions(+)
Upstream bug report for the JUCE framework where this header is used: https://github.com/juce-framework/JUCE/issues/1044
(In reply to Konstantin Belousov from comment #1) FYI: cppreference lists this header as supported: https://en.cppreference.com/w/cpp/header/stdatomic.h
(In reply to Yuri Victorovich from comment #5) As described in Comment 2 and Comment 3, this issue is now resolved.
Does this need to be merged into 13 before 13.1?
I think it should be since it is C++ standard to accept <stdatomic.h>.
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=123b4031e96da7953704d027c41d72d8ec0bf77d commit 123b4031e96da7953704d027c41d72d8ec0bf77d Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2022-03-27 21:16:15 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2022-04-04 22:55:33 +0000 sys/stdatomic.h: be nicer to c++ PR: 262683 (cherry picked from commit c1a24b9dbeade11bfeedc91996672582f6ea32f2) sys/sys/stdatomic.h | 10 ++++++++++ 1 file changed, 10 insertions(+)
I think this can be closed now