<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"><br>
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>
<div>
<div>On Dec 16, 2013, at 4:31 AM, Jay K <<a
moz-do-not-send="true" href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>>
wrote:</div>
<br>
</div>
</blockquote>
Any code that was built to handle multiple character code sequences
will break.<br>
i.e. any correctly implemented code that relies on UTF-16LE as
currently provided<br>
expanding this range would be inherently non-portable.<br>
(... and it could even cause additional problems for when it came to
interface with Xorg and Qt.)<br>
I'd believe that relying on a fixed range of values is going to be
crucial for any kind of character type.<br>
You did not expand the CHAR type to 16 or 32bit either though that
could even have caused less problems.<br>
Writing code that manipulates characters is simply very different
from writing code that does some calculation<br>
based on integer numbers.<br>
</body>
</html>