<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Am 16.12.13 16:00, schrieb Tony
Hosking:<br>
</div>
<blockquote
cite="mid:48D9B4D9-0732-4C96-BB77-598987C22D85@cs.purdue.edu"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>Jumping in late to this whole conversation (please forgive
any confusion)...</div>
<div><br>
</div>
<div>I hesitate to define ANY M3 builtin type in terms of C/C++
standards.</div>
<div>Regarding WIDECHAR, realize that its definition, like CHAR,
should be in terms of an enumeration containing some (minimal)
number of elements.</div>
<div>The standard says that CHAR contains at least 256 elements.</div>
<div>In M3 enumerations all have a direct mapping to INTEGER.</div>
<div>So, I assume that WIDECHAR would be UTF-32, and TEXT could be
encoded as UTF-8.</div>
<div>More radically, what current code will break if CHAR is
expanded to UTF-32?</div>
<div>The language definition would allow that (there is nothing
that says BITSIZE(CHAR) == 8).</div>
<div><br>
</div>
</blockquote>
Well, if so I could rewrite some code to define as BITS 16 FOR
WIDECHAR as WCHAR.<br>
Perhaps that would be the way to go.<br>
However as Rodney M. Bates has said current WIDECHAR is not BITS 16
for UCHAR.<br>
It uses LE encoding rather than host order encoding a fact which one
could be quite<br>
happy about when it comes to extend Trestle/X11 for widechar
support. So even that<br>
would fail when it came to interface with X11 (or otherwise one
would have to maintain<br>
two branches of code all the time; one that does byte swapping and
one that does not<br>
depending on the host order AND the internally used wchar order
which could then <br>
differ as well.).<br>
</body>
</html>