On Fri, 26 Jan 2024 at 11:34, Nina Dinka Ranns via Liaison <
liaison_at_[hidden]> wrote:

> Hi all,
>
> with the release of C23, the C++ standard needs to be updated too.
> We're looking for a volunteer or a group of volunteers to help with that
> effort. I'm cheekily adding the people who did this for C11 in hope of
> getting them interested in doing the same thing again. :)
>

Some notes on the changes to the standard library in C2x, taken from
https://en.cppreference.com/w/c/23 (I'm ignoring the core language changes,
that's somebody else's job ;-)

Removed from C:

- Support for calling realloc() with zero size (the behavior becomes
undefined)

This will affect C++ as we just incorporate realloc by reference. Seems OK,
it just needs to be documented in Clause C.

- __alignof_is_defined and __alignas_is_defined

We already deprecated the latter ready to remove it when we do the rebase.
For some reason C++ never had the former (probably an error), so we're
adding it and deprecating it via an LWG issue:
https://cplusplus.github.io/LWG/issue4036

- static_assert is not provided as a macro defined in <assert.h> (becomes a
keyword)
- thread_local is not provided as a macro defined in <threads.h> (becomes a
keyword)

These don't affect C++, we never had those macros (and don't have
<threads.h> at all).

Deprecated in C:

- <stdnoreturn.h>

Not present in C++ at all.

- Old feature-test macros
        __STDC_IEC_559__
        __STDC_IEC_559_COMPLEX__

Not present in C++.

- asctime()
- ctime()

We incorporate these by reference, but C++ already provides other
facilities for formatting times without depending on global state.

- DECIMAL_DIG (use the appropriate type-specific macro (FLT_DECIMAL_DIG,
etc) instead)
- Definition of following numeric limit macros in <math.h> (they should
be used via <float.h>)
        INFINITY
        DEC_INFINITY
        NAN
        DEC_NAN

We'll pick up these changes by reference too. Seems fine for them to be
deprecated in C++, we already have the FLT_DECIMAL_DIG, DBL_DECIMAL_DIG
etc. macros, as well as std::numeric_limits.

    __bool_true_false_are_defined

This is already deprecated in C++23, ready to remove it at a later date.

- New library headers <stdbit.h> and <stdckdint.h>.
The former would come along with _BitInt if we add that to the core
language, and should be explicitly noted as absent otherwise.
The latter provides extremely useful functionality, but we probably want a
more C++-like interface, and maybe add them to <numeric> alongside the new
saturation arithmetic functions. 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. I'll raise this with LEWG.

- decimal floating-point math functions
We don't have DFP (there was a TS but it's outdated and needs a revision).

- floating-point formatting functions
Redundant with std::to_chars and std::to_string, but I see no harm in
incorporating them by reference.

- library support for UTF-8
We already have char8_t (and its atomic cousin). mbrtoc8 and c8rtomb are
better than nothing, but being tied to the global C locale makes them of
limited use in C++. We really want something that works with the encoding
of an arbitrary std::locale (or at least a ::locale_t, or just POSIX iconv)
not dependent on global state. I've emailed SG16 about the two new
functions.

- memset_explicit
I assume we want this.

- POSIX functions memccpy, strdup, strndup, gmtime_r, localtime_r,
extensions for strftime and wcsftime.
I assume we want these too (the time ones are improvements on what's in C
today, but still less flexible than std::chrono).

- extensions for fscanf and fprintf function families.
You can already do all of this with iostreams and std::to_string and
std::sto* and there's a proposal for std::scan, so meh. But we might as
well have them.

- timespec_getres
The timespec_get API is difficult to reconcile with POSIX clock APIs,
unfortunately: https://www.openwall.com/lists/libc-coord/2023/04/25/2
I doubt anybody cares about this in C++. I doubt most people even know it
exists. I'm OK if it we take it as long as people continue to be unaware it
exists.

- Macro constants for width of integer types
- Additional numeric limit macros for floating-point types
We already have std::numeric_limits for it, but I still use these (but
maybe that's because I'm implementing a stdlib and for normal users
std::numeric_limits is the right choice). We might as well have them.

- Library version-test macros
I don't think we want these, we have a different way of doing feature-test
macros. We might want some new __cpp_lib_xxx macros that depend on the
underlying libc ones though.