These macros are lacking of the `L` suffix compared to the content of the table in [support.limits.general]. This can lead to some unexpected effects on observable behavior, e.g.: #include <string> #include <iostream> #define macro_as_string(x) #x #define stringized_length(x) std::string(macro_as_string(x)).size() int main() { std::cout << stringized_length(__cpp_lib_nonmember_container_access); } Also, in <bits/allocator.h>, `__cpp_lib_allocator_traits_is_always_equal` is wrongly spelled as `__cpp_lib_allocator_is_always_equal`.
The original macros in the Library Fundamentals TS were ints not longs, which is why some started that way. I've been gradually fixing them, but it's very, very low priority. Your example doesn't seem very realistic. The allocator traits one is a bug though.
I agree the problem of 'L' is not likely found as a real issue in practice. Perhaps this could be forwarded as an issue of the standard which requires overspecified definitions. I don't find any intentional use cases about relying on the exactly specified type. (Despite the range limitation of int, the macro expansion results can be specified as "integer literal equal to the corresponding numerical values specified in the table" and a note about intentionally unspecified types.)
(In reply to frankhb1989 from comment #0) > Also, in <bits/allocator.h>, `__cpp_lib_allocator_traits_is_always_equal` is > wrongly spelled as `__cpp_lib_allocator_is_always_equal`. This is incorrect. We *also* define __cpp_lib_allocator_traits_is_always_equal, in the appropriate places. So we have an extra, non-standard macro. We don't spell the standard one wrong. The allocator_is_always_equal spelling was present in http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4440.html#recs.cpp17 and in http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0096r0.html#detail.cpp17 but gone in http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0096r1.html#recs.cpp17
(In reply to Jonathan Wakely from comment #3) > (In reply to frankhb1989 from comment #0) > > Also, in <bits/allocator.h>, `__cpp_lib_allocator_traits_is_always_equal` is > > wrongly spelled as `__cpp_lib_allocator_is_always_equal`. > > This is incorrect. We *also* define > __cpp_lib_allocator_traits_is_always_equal, in the appropriate places. So we > have an extra, non-standard macro. We don't spell the standard one wrong. > OK, I see N4258 proposes changes both to [allocator.traits] and [default.allocator]. The macro `__cpp_lib_allocator_is_always_equal` is likely only for the latter and it's in the right header. Not a bug. The issue is remained for 'L'.
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>: https://gcc.gnu.org/g:d0330a03606d06dc4084e9c8734a549d22676463 commit r10-8022-gd0330a03606d06dc4084e9c8734a549d22676463 Author: Jonathan Wakely <jwakely@redhat.com> Date: Tue Apr 28 23:31:04 2020 +0100 libstdc++: Fixes for feature test macros (PR 91480) Remove the non-standard __cpp_lib_allocator_is_always_equal macro and add the missing macros for P1032R1. PR libstdc++/91480 * include/bits/allocator.h (__cpp_lib_allocator_is_always_equal): Remove non-standard macro. * include/bits/stl_iterator.h (__cpp_lib_constexpr_iterator): Define to indicate P1032R1 support. * include/bits/stl_pair.h (__cpp_lib_constexpr_utility): Likewise. * include/std/string_view (__cpp_lib_constexpr_string_view): Likewise. * include/std/tuple (__cpp_lib_constexpr_tuple): Likewise. * include/std/version (__cpp_lib_allocator_is_always_equal): Remove. (__cpp_lib_constexpr_iterator, __cpp_lib_constexpr_string_view) (__cpp_lib_constexpr_tuple, __cpp_lib_constexpr_utility): Define. * testsuite/20_util/function_objects/constexpr_searcher.cc: Check feature test macro. * testsuite/20_util/tuple/cons/constexpr_allocator_arg_t.cc: Likewise. * testsuite/21_strings/basic_string_view/operations/copy/char/ constexpr.cc: Likewise. * testsuite/24_iterators/insert_iterator/constexpr.cc: Likewise.
(In reply to Jonathan Wakely from comment #3) > (In reply to frankhb1989 from comment #0) > > Also, in <bits/allocator.h>, `__cpp_lib_allocator_traits_is_always_equal` is > > wrongly spelled as `__cpp_lib_allocator_is_always_equal`. > > This is incorrect. We *also* define > __cpp_lib_allocator_traits_is_always_equal, in the appropriate places. So we > have an extra, non-standard macro. We don't spell the standard one wrong. > > The allocator_is_always_equal spelling was present in > http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4440.html#recs.cpp17 > and in > http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0096r0.html#detail. > cpp17 but gone in > http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0096r1.html#recs.cpp17 I've removed __cpp_lib_allocator_is_always_equal for GCC 10.
There's already a bug about the int vs long definitions. *** This bug has been marked as a duplicate of bug 87193 ***