Re: ucs4_t type

[Bruno Haible]

Paolo Bonzini wrote:
> BTW, there's an interesting difference between char32_t and ucs4_t, in 
> that the former has "the same size, signedness, and alignment as 
> uint_least32_t", while libunistring uses uint32_t to define the latter.

This is because libunistring (and gnulib) simply assume that uint32_t
exists. We don't attempt portability to platforms with 36-bit register
words.

>   I wonder if libunistring should be changed to:
> 
> 1) detect _Char32_t (or uchar.h and char32_t) and use it if available,

You would have to be careful when doing this:
  * This definition could only be done when char32_t exists as a type
    and if __STDC_UTF_32__ is defined to 1. But this depends on the
    compiler brand and version. Shared libraries must have an ABI that
    is independent of the compiler.
  * Also, compilers could define char16_t to be uint32_t, or char32_t to
    be uint64_t, which would be a binary incompatible change.

Basically, I don't think many applications will use char16_t and char32_t
in portable programs on Unix, because these types are useless when
__STDC_UTF_32__ is not defined. The C1X [1] standard designers are repeating
the same mistake they did with wchar_t. The reason wchar_t did not take
off on Unix is that its encoding is platform dependent. The proposed C1X
standard specifies the same thing for char16_t and char32_t ([2] p. 560).

Bruno

[1] http://en.wikipedia.org/wiki/C1X
[2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1494.pdf