On 26.02.2020 14:49, Joerg Sonnenberger wrote: > On Wed, Feb 26, 2020 at 12:37:06PM +0100, Kamil Rytarowski wrote: >> I propose to expose max_align_t unconditionally to C and C++ namespaces. >> >> It was introduced in C11/C++11, but in practice it is used in C++ code >> that formally builds in the C++03/older mode (llvm libc++ expects it >> unconditionally). >> >> http://netbsd.org/~kamil/patch-00237-max_align_t.txt >> >> Instead of adding fallback definitions in third party code like in llvm >> libc++ (there was an attempt for this in libc++, but reverted) it is >> easier to expose it in our headers as expected unconditionally. > > Please don't interprete events without knowing the background. It was an > unintentional push due to git $#%^$#^ behavior. The patch is under > review and discussion and the test fallout that triggered it is a bug in > the test suite. The libc++ behavior here is plain wrong and that is > generally agreed upon. > > Joerg > Is it worth our time to patch for pre-c++11 environment? C++11 is now mainstream for 9 years and as far as I recall libc++ was designed as C++11 & newer C++ runtime library only with some fallback as much as reasonable to older revisions of C++. Today we require both C11 and C++11 compiler to build our distribution. If we want to maintain internal max_align_t inside a C++ runtime that is expected to be essentially the same as max_align_t from headers, we need to maintain the same code that is ABI sensitive in two places now. This "plain wrong" mistake is now apparently relevant only to NetBSD as no other libc++ user is bothered, even if they can agree that this is not fully correct. max_align_t's definition does not need any compiler features that predate C99/C++98. I can lower the requirements to >=C99 || C++ and we can be done. C99 is formally needed for long long int. We try to use libc++ and this is now one of our blockers. If someone really cares about libc++ internals, they could be patched independently.
Description: OpenPGP digital signature