<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>