On Tue, 17 Sept 2024 at 19:12, Jens Maurer <jens.maurer_at_[hidden]> wrote:

>
>
> On 17/09/2024 16.22, Jonathan Wakely wrote:
> >
> >
> > On Tue, 17 Sept 2024 at 15:01, Inbal Levi <sinbal2l_at_[hidden] <mailto:
> sinbal2l_at_[hidden]>> wrote:
> >
> > Thank you, Jonathan!
> > Adding chair for today (Fabio) and co-chairs as FYI.
> >
> > > We also haven't got a decision on what to do with the new math and
> numerics stuff in C23.
> > True. I see the new utils are not added as part of your paper, so we
> can move forward with the paper today. We'll get back to that when we have
> SG4's input.
> > I'll ping Mattias (I thought I did, but must have forgotten to..)
> >
> > > LEWG should decide whether to incorporate <stdckint.h> as-is if
> we're not going to have something like it in time for C++26 (0). (from
> document)
> > > C++ has no equivalent currently, but we probably don’t want
> type-generic macros like C has. (from P3348R0)
> > > For stdckdint.h we're not going to use the C header, so should not
> define the C macro.
> >
> > I was referring to this as an open question, as it wasn't voted on
> yet, but I know your paper doesn't propose adding it.
> > I (personally) agree that having this in C++ shape is better (and we
> might need a follow-up paper for that), and that it's probably better to
> have nothing in 26 than adding the C shape.
> > Might be worth bringing up in LEWG (and if they do ask to add the C
> shape as well, then figure out what to do).
> >
> >
> > P3370 already has the macro, so I don't think we need to figure out what
> to do if LEWG do want it.
> >
> > I assume the motivation for adding it was so mixed C/C++ headers can use
> the same macro to check for the features whether the header is compiled as
> C or C++/
>
> Exactly.
>
> C-style code being compiled as C++ might want to do #ifdef __something
> from the C standard, so the corresponding macro should be defined if
> we provide that functionality with the C interface.
>

It gets more complicated for __STDC_VERSION_STDDEF_H__ where the C++
version will not #define unreachable, and for __STDC_VERSION_STDLIB_H__
where the C++ version does not provide ::call_once. Should we prevent
declaring the macros so we don't claim to support things that aren't there?



> C++ feature-test macros should not be added for anything we take 1:1 from
> C.
>
> Jens
>