Re: [PATCH 2/3]: C++20 P0482R6 and C2X N2653: Implement mbrtoc8, c8rtomb, char8_t

[Joseph Myers <joseph@codesourcery.com>]

On Fri, 11 Jun 2021, Tom Honermann via Libc-alpha wrote:

> 1) Enabling pre-C2x compatibility with C++20.

Where a feature in a header should be enabled for a particular C++ 
version, we can have an internal __GLIBC_USE (CXX20) which is enabled 
based on the value of __cplusplus, just like the existing __USE_ISOCXX11.  
(Though that doesn't make much practical difference until we provide a way 
for C++ library headers to get all the features they need without defining 
_GNU_SOURCE.)

You'd then have

#if defined __USE_GNU || __GLIBC_USE (CXX20)

in uchar.h, with appropriate !defined __cpp_char8_t for defining the 
typedef itself.  And the defined __USE_GNU would become __GLIBC_USE 
(ISOC2X) if the feature is accepted for C2x.

> 2) Enabling conditional code sensitive to the change of type of u8 string
> literals.

That might be a reason for a compiler option (I don't think it's a 
sufficient reason, I expect -std=c11 or -Wno-pointer-sign or pointer casts 
to suffice in practice), but it has nothing to do with the use of feature 
test macros in glibc since the library headers don't care at all what the 
type of u8 string literals is (there are no u8 string literals anywhere in 
glibc).

> 3) Avoiding clashes with existing uses of the char8_t identifier in code that
> may be compiled with _GNU_SOURCE.

It's a universal feature in glibc that all non-obsolescent, 
non-conflicting features are enabled with _GNU_SOURCE, including features 
from future standard versions - all feature test macros are subsets of 
_GNU_SOURCE, except where the features actually conflict in some way (a 
few cases where a POSIX function has semantics incompatible with a GNU 
function of the same name), and features from future standards with no 
feature test macro support in glibc (e.g. some features proposed for the 
next POSIX version) are also enabled by _GNU_SOURCE.

So char8_t and these functions should be enabled by _GNU_SOURCE, 
regardless of what other options enable them.

Users of _GNU_SOURCE are expected to deal with possible naming conflicts 
with features added to _GNU_SOURCE.  Likewise people building with 
-std=gnu2x / -std=c2x, which would enable these declarations if char8_t 
and these functions are added to C2x, or users of _ISOC2X_SOURCE (which 
isn't expected to be used much).

> I agree that this is a narrow feature, but I think the feature test macro is
> beneficial for compatibility reasons.  Assuming the proposal is adopted for
> C23, some programmers may need to opt-out of the feature by compiling with
> -fno-char8_t during a migration period; as some C++20 projects have done.

We don't provide a way to opt out of any other library additions when 
compiling in C2x mode; compiling with -std=c2x or -std=gnu2x or 
-D_GNU_SOURCE unconditionally enables all other C2x additions in headers 
(including e.g. the iszero macro, although the issues seen with that were 
mainly for C++ code and we addressed that by making it a template instead 
of a macro for C++), compiling with e.g. -std=c11 or -std=gnu11 (and not 
using _GNU_SOURCE) is how you opt out of all such additions at the same 
time.  Likewise for previous C standard versions.  And _GNU_SOURCE is the 
universal way to opt in to features that might or might not be in a future 
standard version.  If such a feature has its own TS, we may support the 
__STDC_WANT_* macros from such a TS, but that's not a basis for creating 
our own feature test macro for a handful of new identifiers.

-- 
Joseph S. Myers
joseph@codesourcery.com