rsmith added a comment.
On the assumption that we will never get a `::max_align_t` in C++98 mode anyway
(which will be the case if the `<stdlib.h>` is conforming), this looks like the
best we can do to me.
================
Comment at: libcxx/include/new:229-237
+#if !defined(_LIBCPP_CXX03_LANG)
+using __libcpp_max_align_t = max_align_t;
+#else
+union __libcpp_max_align_t {
+ void * __f1;
+ long long int __f2;
+ long double __f3;
----------------
Is there any ODR risk from this, or similar? Does libc++ support building in
mixed C++98 / C++11 mode? If different TUs disagree on this alignment, we can
end up allocating with the aligned allocator and deallocating with the
unaligned allocator, which is not guaranteed to work.
We could always use the union approach if we don't know the default new
alignment. But from the code below it looks like we might only ever use this if
we have aligned allocation support, in which case we can just assume that the
default new alignment is defined. So perhaps we can just hide the entire
definition of `__is_overaligned_for_new` behind a `#ifdef
__STDCPP_DEFAULT_NEW_ALIGNMENT__` and never even consider `max_align_t`?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D73245/new/
https://reviews.llvm.org/D73245
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
