tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Expose max_align_t unconditionally



On Mon, 2020-03-09 at 20:05 +0100, Martin Husemann wrote:
> 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).

I don't think that's the case.  AFAIK the problem is really that they
don't want to go out of their way to hide symbols for older C++
standards.

To be honest, this is NetBSD-specific problem.  Upstream has a fallback
for other platforms but it was explicitly disabled on NetBSD (Kamil or
Joerg will probably know why).

> 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

I don't really see why this would really break anything.  Worst case, it
will encourage people to write less portable software.

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

ATF-C++ forces -std=gnu++98.  We could remove that but then we fail
on deprecated auto_ptr use.  We can add -Wno-error=... though.

>  - 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++?
> 

<cstddef> has:

  using ::max_align_t;

and it is pulled by some other headers.

-- 
Best regards,
Michał Górny

Attachment: signature.asc
Description: This is a digitally signed message part



Home | Main Index | Thread Index | Old Index