Wide_Character vs. Interfaces.C.wchar_t

Wide_Character vs. Interfaces.C.wchar_t

[Florian Weimer]

ARM B.3 seems to imply the existance of a bijective mapping between
Wide_Character and Interfaces.C.wchar_t.  ARM 3.5.2(3) requires that
Wide_Character has exactly 2**16 distinct values.  What shall be done
if wchar_t (the C version) has more than just 16 significant bits?

This isn't just a theoretical question because with GNU libc 2.1.2,
wchar_t type has actually 32 significant bits (and GNAT declares
Interfaces.C.wchar_t so that its size is 16 bits, which seems to
be wrong).

Re: Wide_Character vs. Interfaces.C.wchar_t

[Keith Thompson]

Florian Weimer <fw@deneb.cygnus.argh.org> writes:
> ARM B.3 seems to imply the existance of a bijective mapping between
> Wide_Character and Interfaces.C.wchar_t.  ARM 3.5.2(3) requires that
> Wide_Character has exactly 2**16 distinct values.  What shall be done
> if wchar_t (the C version) has more than just 16 significant bits?

I don't think the mapping has to be bijective (assuming my memory of
what that word means is correct ... consulting reference library ...
not in dictionary ... trying CRC Math Tables ...  yeah, that's what I
thought).  If wchar_t is 32 bits, presumably To_Ada would throw away
the top 16 bits, and To_C would set them to 0.  (Or one could argue
that To_Ada should raise Constraint_Error if the argument won't fit in
16 bits.)

The same situation occurs for Character and Interfaces.C.char; the
only requirement imposed by the C standard is that char must have a
range of at least -127..+127 or 0..255 (it can be either signed or
unsigned).  As it happens, almost all existing C compilers use 8 bits
for char, so this doesn't tend to arise in real life.

BTW, there is (at least) one problem with Interfaces.C: the
declaration of wide_nul is

    wide_nul : constant wchar_t := wchar_t'First;

which is clearly wrong if wchar_t is signed, as it is on at least some
systems.  I think there's an AI for this.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
"Oh my gosh!  You are SO ahead of your time!" -- anon.

Re: Wide_Character vs. Interfaces.C.wchar_t

[Lutz Donnerhacke]

* Keith Thompson wrote:
>unsigned).  As it happens, almost all existing C compilers use 8 bits
>for char, so this doesn't tend to arise in real life.

A lot of embedded controller compilers do have 32/64bit for a char. They
can't deal with smaller values.
\f
We noticed it, because the C standard requires sizeof(char) to be one.
So we have sizeof(char) == sizeof(short) == sizeof(int) == sizeof(long) ==
sizeof(long long) == 1 on this machine, causing the problem, that the
following common construct stops on the input char -1:
  int c; while(EOF != (c = getchar())) ...
\f
F'up poster.