<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Libedit internally uses wchar_t to
handle wide characters. For the types of things libedit does, I
think a wchar_t is better suited than an array of utf8 coded
bytes. The translations in question are for getting data in and
out of libedit. <br>
<br>
This means that support for extended characters in the command
line history will be dependent on having <codecvt> support
and a libedit built with wchar-t support, which, AFAIK, is only
OSX.<br>
<br>
Currently, I am reworking the patch, so it works with either
libedit's char or wchar_t functions. This is a compile time
decision.<br>
<br>
If we want wide character support on other platforms down the
road, it would make sense to bring the libedit functions into
lldb. We can add a custom wchar to utf8 translations if gcc
still does not support <codecvt>. <br>
<br>
On 10/29/2014 11:38 AM, Zachary Turner wrote:<br>
</div>
<blockquote
cite="mid:CAAErz9i2rWAfoHny3gJSqqdppkYAvne3b3mTbF6jWjLwSBr_oQ@mail.gmail.com"
type="cite">If you're storing UTF8 anyway, why not just use
regular character strings? Doesn't it defeat the purpose of using
UTF8 if you're combining it with a character type that isn't 1
byte?<br>
<br>
<div class="gmail_quote">On Wed Oct 29 2014 at 11:27:29 AM Kate
Stone <<a moz-do-not-send="true"
href="mailto:katherine_stone@apple.com">katherine_stone@apple.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>On Oct 28, 2014, at 1:55 PM, Zachary Turner <<a
moz-do-not-send="true" href="mailto:zturner@google.com"
target="_blank">zturner@google.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div class="gmail_quote">On Tue Oct 28 2014 at 1:46:26
PM Vince Harron <<a moz-do-not-send="true"
href="mailto:vharron@google.com" target="_blank">vharron@google.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br>
</div>
<div dir="ltr">
<div><font face="arial, sans-serif">> </font><span
style="font-family:arial,sans-serif;font-size:13px">- rework the
Editline rewrite, so it either uses standard 8
bit chars, or wchar_t/utf8 depending on the
platform. This would be conditionally built
depending on the platform.</span></div>
<div><span
style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
</div>
<div dir="ltr">
<div><span
style="font-family:arial,sans-serif;font-size:13px">This
would be my favorite option if possible.
wchar_t never really took roots in Linux
AFAIK.</span></div>
</div>
</blockquote>
<div><br>
</div>
<div>Also probably the best option for Windows,
although it's worth pointing out that at least for
now, most other stuff in LLDB doesn't really use
wide character strings either, so char would be the
path of least resistance for Windows right now.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div dir="auto">
<div>With the Editline rewrite I made the explicit decision
to insulate the rest of LLDB from wide characters and
strings by encoding everything as UTF8. I agree that
reverting to char-only input is a perfectly reasonable
solution for platforms that don't yet include wchar-aware
libedit implementations.</div>
<div><br>
</div>
<div style="word-wrap:break-word"><span
style="background-color:rgba(255,255,255,0)">Kate Stone <a
moz-do-not-send="true" href="mailto:k8stone@apple.com"
target="_blank">k8stone@apple.com</a></span></div>
<div style="word-wrap:break-word"><span
style="background-color:rgba(255,255,255,0)"> Xcode Runtime
Analysis Tools</span></div>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>