<div class="gmail_quote">On Sun, Jul 31, 2011 at 01:30, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>On Sun, Jul 31, 2011 at 12:58 AM, Sean Hunt <<a href="mailto:scshunt@csclub.uwaterloo.ca" target="_blank">scshunt@csclub.uwaterloo.ca</a>> wrote:<br>
> What possibility is this? \UFFFFFFFF is far from valid, and no other<br>
> character escape can get anywhere near that high.<br>
<br>
</div>L"\xFFFFFFFF" is allowed, though...<br>
<font color="#888888"><br>
-Eli<br>
<br>
</font></blockquote></div>Ah, yes, I'd forgotten that hex escapes can have infinite length.<br><br>One possible approach is to implement the logical extension of UTF-8 up to 32 bits. This would be a truly horrid encoding for exceptionally large values, but would be internally consistent and allow us to handle  it if someone decides they actually want L'\xFFFFFFFF' to be a valid wchar_t constant.<br>

<br>Sean<br>