On 04/04/2024 17.37, Aaron Ballman via Liaison wrote:
> Okay, that leaves some really interesting situations then.
>
> Should #include <stdbit.h> compile because it's not mentioned at all
> by the C++ standard and so it's basically a user-provided header?
>
> Should use of strdup from <string.h> compile despite not being in C17,
> because it is in POSIX?

We all understand that POSIX adds names to all kinds of C headers.
However, when compiling C++, <string.h> is a header defined by
the C++ standard (not by e.g. the C standard or POSIX).
That's the de-jure answer.

> Should use of __STDC_VERSION_LIMITS_H__ from <limits.h> not compile
> because it wasn't in C17 nor in POSIX?

That one doesn't matter because it's a double-underscore name that
users couldn't have used anyway.

> I don't see how users are served by anything other than providing the
> interfaces from the header they included. I don't think it's
> defensible from an implementation perspective to say "we will only
> give you some C standard interfaces in C++ mode, based on which C
> standard the C++ library was based on at the time" -- that is just
> inexplicable to anyone but a committee member and seems like a burden
> on implementers because that also means C11 interfaces can't be
> exposed in C++14 or C++11 mode, etc.
>
> Also, I can't square how that fits with "The intended use of these
> headers is for interoperability only. It is possible that C++ source
> files need to include one of these headers in order to be valid ISO C.
> Source files that are not intended to also be valid ISO C should not
> use any of the C headers."
>
> If it's for interoperability with valid ISO C... C23 is valid ISO C
> whether WG21 has rebased or not.

The C++ standard refers to a specific version of ISO C, so any mention
of "ISO C" is to be read as "ISO C18", not any future version.

>> Why, for heaven's sake, is 'unreachable' a macro in C? That is instant
>> trouble for C++,
>> where every user expects to be able to scope names via namespaces.
>
> I'm not interested in rehashing decisions that are already too late
> for either committee to change, just trying to figure out how to move
> forward within the world we have.

Then go forward with whatever you feel you want to do.
Personally, I'd expect C++, when it's rebased on C, to say that
"unreachable" is never a macro even after #include <stddef.h>,
because it jeopardizes the spelling "std::unreachable()", which
is the "natural" C++ spelling of the facility.

Jens