Re: Wide_Character vs. Interfaces.C.wchar_t

[Keith Thompson <kst@cts.com>]

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.