<DIV style="font-family:Arial, sans-serif; font-size:10pt;"><BR><BR>-Rodney Bates<BR><BR>--- hosking@cs.purdue.edu wrote:<BR><BR>  From: Tony Hosking <hosking@cs.purdue.edu><BR>  To: Jay K <jay.krell@cornell.edu><BR>  Cc: "Rodney M. Bates" <rodney_bates@lcwb.coop>,        m3devel <m3devel@elegosoft.com><BR>  Subject: Re: [M3devel] cm3 does not support Scan.LongInt<BR>  Date: Mon, 16 Dec 2013 10:00:40 -0500<BR><BR><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.><BR></DIV><DIV>> Regarding WIDECHAR, realize that its definition, like CHAR, should be in terms <BR>> 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).<BR><BR>I have thought about this many times.  Without debating the whether it's good or bad,<BR>changing CHAR to other than exactly 256 would break all kinds of stuff.  The language<BR>says "at least", but a large fraction of existing low level code assumes ORD(LAST(CHAR)) = 255,<BR>or, more importantly, ADRSIZE(CHAR) = BYTESIZE(CHAR) = 1.  I would guess the GC<BR>contains a lot of this kind of code.  Certainly Pickles, network objects, TEXT itself, and<BR>lots of the RTS does.  <BR></DIV><DIV><BR></DIV><BR></DIV>