Define char16_t, char32_t consistently with uint_least16_t, uint_least32_t (bug 17979)

  As noted in bug 17979 (and as I noted earlier in
<https://sourceware.org/ml/libc-alpha/2012-02/msg00647.html>), uchar.h
has gratuitously complicated code to determine the types for char16_t
and char32_t, and to reject including that header for pre-C11
compilers not defining __CHAR16_TYPE__ and __CHAR32_TYPE__.  Since
those types are always required to match uint_least16_t and
uint_least32_t, which glibc knows how to define without reference to
such predefined macros, it's safe just to define those types the same
as the *least* types are defined in stdint.h, so allowing the header
to work with (for example) GCC 4.3.

This patch implements that.  bits/types.h is made to define
__int_leastN_t and __uint_leastN_t so the logic for those types can
stay in a single place, and stdint.h is made to use those __*_t to
define the public *_t types.  uchar.h is then made to use
__uint_least16_t and __uint_least32_t to define char16_t and char32_t,
so simplifying the logic there.  A new test is added that verifies the
types chosen for char16_t and char32_t do indeed match the types the
compiler uses for u"" and U"" string literals.

Tested for x86_64.  (I have not tested with any of the older compilers
for which this would actually make a difference to whether you can
include uchar.h.)

2018-02-01  Joseph Myers  <joseph@codesourcery.com>

	[BZ #17979]
	* posix/bits/types.h (__int_least8_t): New typedef.
	(__uint_least8_t): Likewise.
	(__int_least16_t): Likewise.
	(__uint_least16_t): Likewise.
	(__int_least32_t): Likewise.
	(__uint_least32_t): Likewise.
	(__int_least64_t): Likewise.
	(__uint_least64_t): Likewise.
	* sysdeps/generic/stdint.h (int_least8_t): Define using
	__int_least8_t.
	(int_least16_t): Define using __int_least16_t.
	(int_least32_t): Define using __int_least32_t.
	(int_least64_t): Define using __int_least64_t.
	(uint_least8_t): Define using __uint_least8_t.
	(uint_least16_t): Define using __uint_least16_t.
	(uint_least32_t): Define using __uint_least32_t.
	(uint_least64_t): Define using __uint_least64_t.
	* wcsmbs/uchar.h: Include <bits/types.h>.
	(char16_t): Define using __uint_least16_t conditional only on
	[!__USE_ISOCXX11].
	(char32_t): Define using __uint_least32_t conditional only on
	[!__USE_ISOCXX11].
	* wcsmbs/test-char-types.c: New file.
	* wcsmbs/Makefile (tests): Add test-char-types.
  

Ping.  This patch 
<https://sourceware.org/ml/libc-alpha/2018-02/msg00032.html> is pending 
review.
  

On 01/02/2018 18:36, Joseph Myers wrote:
> As noted in bug 17979 (and as I noted earlier in
> <https://sourceware.org/ml/libc-alpha/2012-02/msg00647.html>), uchar.h
> has gratuitously complicated code to determine the types for char16_t
> and char32_t, and to reject including that header for pre-C11
> compilers not defining __CHAR16_TYPE__ and __CHAR32_TYPE__.  Since
> those types are always required to match uint_least16_t and
> uint_least32_t, which glibc knows how to define without reference to
> such predefined macros, it's safe just to define those types the same
> as the *least* types are defined in stdint.h, so allowing the header
> to work with (for example) GCC 4.3.
> 
> This patch implements that.  bits/types.h is made to define
> __int_leastN_t and __uint_leastN_t so the logic for those types can
> stay in a single place, and stdint.h is made to use those __*_t to
> define the public *_t types.  uchar.h is then made to use
> __uint_least16_t and __uint_least32_t to define char16_t and char32_t,
> so simplifying the logic there.  A new test is added that verifies the
> types chosen for char16_t and char32_t do indeed match the types the
> compiler uses for u"" and U"" string literals.
> 
> Tested for x86_64.  (I have not tested with any of the older compilers
> for which this would actually make a difference to whether you can
> include uchar.h.)

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

> +
> +#include <uchar.h>
> +
> +const char16_t *s16 = u"";
> +const char32_t *s32 = U"";
> +
> +static int
> +do_test (void)
> +{
> +  /* This is a compilation test.  */
> +  return 0;
> +}
> +
> +#include <support/test-driver.c>

Maybe we could add these kind of tests on build time to catch on cross-compilation,
as:

#define is_compatible(x, T) _Generic((x), T:1, default: 0)
#define check_compatibility(x, t) \
  _Static_assert (is_compatible (x, t), "type not compatible")

  check_compatibility (u"", char16_t *);
  check_compatibility (U"", char32_t *);
  

On Wed, 7 Feb 2018, Adhemerval Zanella wrote:

> > +#include <uchar.h>
> > +
> > +const char16_t *s16 = u"";
> > +const char32_t *s32 = U"";
> > +
> > +static int
> > +do_test (void)
> > +{
> > +  /* This is a compilation test.  */
> > +  return 0;
> > +}
> > +
> > +#include <support/test-driver.c>
> 
> Maybe we could add these kind of tests on build time to catch on 
> cross-compilation, as:

The test above is fully functional for cross compilation (provided you 
compile the testsuite, not just glibc itself, of course).

> #define is_compatible(x, T) _Generic((x), T:1, default: 0)
> #define check_compatibility(x, t) \
>   _Static_assert (is_compatible (x, t), "type not compatible")
> 
>   check_compatibility (u"", char16_t *);
>   check_compatibility (U"", char32_t *);

This would be problematic because of -Wwrite-strings meaning the types end 
up as const char16_t * and const char32_t *.  The test as written works 
whether or not the type ends up being const-qualified.  (You don't want a 
test that actually relies on -Wwrite-strings being in use to get the 
tested-for type, because it's not ideal that -Wwrite-strings works by 
changing types of string constants; see GCC bug 61579.)
  

On 07/02/2018 18:30, Joseph Myers wrote:
> On Wed, 7 Feb 2018, Adhemerval Zanella wrote:
> 
>>> +#include <uchar.h>
>>> +
>>> +const char16_t *s16 = u"";
>>> +const char32_t *s32 = U"";
>>> +
>>> +static int
>>> +do_test (void)
>>> +{
>>> +  /* This is a compilation test.  */
>>> +  return 0;
>>> +}
>>> +
>>> +#include <support/test-driver.c>
>>
>> Maybe we could add these kind of tests on build time to catch on 
>> cross-compilation, as:
> 
> The test above is fully functional for cross compilation (provided you 
> compile the testsuite, not just glibc itself, of course).
> 
>> #define is_compatible(x, T) _Generic((x), T:1, default: 0)
>> #define check_compatibility(x, t) \
>>   _Static_assert (is_compatible (x, t), "type not compatible")
>>
>>   check_compatibility (u"", char16_t *);
>>   check_compatibility (U"", char32_t *);
> 
> This would be problematic because of -Wwrite-strings meaning the types end 
> up as const char16_t * and const char32_t *.  The test as written works 
> whether or not the type ends up being const-qualified.  (You don't want a 
> test that actually relies on -Wwrite-strings being in use to get the 
> tested-for type, because it's not ideal that -Wwrite-strings works by 
> changing types of string constants; see GCC bug 61579.)
> 

Fair enough.