Re: Expose max_align_t unconditionally

[Martin Husemann <martin%duskware.de@localhost>]

On Mon, Mar 09, 2020 at 02:49:23PM -0400, Greg Troxel wrote:
> I am not really following the issue, but I don't understand why what the
> default C++ sublanguage is matters.  It would seem that behavior should
> be correct for any --std passed to compilers, per that sublanguages's
> specification, and what you get by default is just what happens to you
> if you don't pass --std.  (And I basically think a  build that does not
> pass an explicit --std is buggy, but that's a separate issue.)

The problem is that this c++ lib does not support compiling with -std=
for standards < C++11 (IIUC).

This is pretty stupid, but IMHO no big deal. We can

 - expose max_align_t (bogusly) for older C++ versions and hope that every
   user of this combination is lucky with other parts of the lib

 - just not support (i.e. #error) on older C++ standard compiles

 - wait for Jörg to win the upstream battle and go with the fixed libc++

As a C++ developer in real life I would not expect much lossage from the
#error variant - most things that really require older standards will have
trouble anyway, and patching the few pkgsrc things that eroneously force
some older C++ version (but actually do not care) is not a big deal.

But I may be overoptimistic ;-)

Michal, what I don't understand: what is the exact failure mode (i.e. what
is a minimal sample to trigger the lossage)? Is max_align_t used in some
header included everywhere, or just specific rarely used headers? Or is
for example our in tree groff version not compilable with that libc++?

Martin