On Thu, Apr 4, 2024 at 10:30 AM Ville Voutilainen
<ville.voutilainen_at_[hidden]> wrote:
>
> On Thu, 4 Apr 2024 at 16:15, Aaron Ballman via Liaison
> <liaison_at_[hidden]> wrote:
> >
> > C23 adds a macro named `unreachable` to <stddef.h>. C++23 adds a
> > function named `std::unreachable` to <utility>. What should the
> > behavior of this code be when compiled in C++23?
> >
> > #include <stddef.h>
> >
> > #ifndef unreachable
> > #error "oh no, my macro!"
> > #endif
> >
> > [support.c.headers.general]p1
> > (https://eel.is/c++draft/support.c.headers#general-1) says:
> >
> > For compatibility with the C standard library, the C++ standard
> > library provides the C headers shown in Table 40. 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.
> >
> > I read this as saying that including a C header in a C++
> > implementation should provide all the interfaces from the C header
> > unless the C++ standard says something else. Since C++23 isn't based
> > on top of C23 and thus says nothing about the `unreachable` macro in
> > stddef.h, I think this implies that the code should compile.
> > (Similarly, including stdbit.h should be fine if the header exists, or
> > including string.h and using strdup or memccpy should work, and so on
> > for all the newly introduced C23 library functionality.) I think this
> > matches user expectations and the intent of the standard, but the
> > situation with unreachable is a bit odd and the question came up
> > during a code review for Clang which removes the macro from stddef.h
> > in C++ mode because of the potential for conflict with the function
> > declared in <utility>.
> >
> > I have two concrete questions:
> >
> > 1) Before WG21 has rebased on top of the latest C, are C++
> > implementations expected to strip out all interfaces from C standard
> > library headers that are not in the version of C which C++ has based
> > the library on?
> >
> > 2) If the answer to #1 is "no, C++ implementations are expected to
> > provide the C interfaces present unless otherwise stated", is
> > unreachable likely to be special when C++ rebases on top of C23?
>
> My spec-squinting suggests that the answer to (1) is yes. The
> normative reference to C
> comes with a date, it refers to C18. I therefore would not expect
> C++23 to bring in C23 entities.
>
> That is also my technical preference; it's ostensibly so that that
> particular version of C
> has been figured out how to make it work with that particular version
> of C++, and newer
> versions of C simply might not work.

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?

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

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.

> 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.

~Aaron