<html><body><p><tt><font size="2">Kamil Rytarowski <n54@gmx.com> wrote on 29.05.2017 18:10:36:<br><br>> Do you offer shell account? I don't have Linux and/or s390x to debug it.<br></font></tt><br><tt><font size="2">Sorry, this is on an internal IBM machine ... I don't have a publically</font></tt><br><tt><font size="2">accessible machine to reproduce this on at the moment.</font></tt><br><br><tt><font size="2">I managed to debug a bit myself, and I think the problem is this:</font></tt><br><br><tt><font size="2">After your change, this routine:</font></tt><br><tt><font size="2">int Editline::GetCharacter(EditLineGetCharType *c) {</font></tt><br><tt><font size="2">now has a "wchar_t *" argument, and stores the output character</font></tt><br><tt><font size="2">as a 4-byte wide character on Linux.</font></tt><br><br><tt><font size="2">However, the caller of this routine does this (this is the Fedora 24</font></tt><br><tt><font size="2">version of libedit - libedit-3.1-14.20150325cvs.fc24.src.rpm):</font></tt><br><br><tt><font size="2">        num_read = (*el->el_read.read_char)(el, cp);</font></tt><br><tt><font size="2">        if (num_read < 0)</font></tt><br><tt><font size="2">                el->el_errno = errno;</font></tt><br><tt><font size="2">#ifdef WIDECHAR</font></tt><br><tt><font size="2">        if (el->el_flags & NARROW_READ)</font></tt><br><tt><font size="2">                *cp = *(char *)(void *)cp;</font></tt><br><tt><font size="2">#endif</font></tt><br><br><tt><font size="2">In my case, the (el->el_flags & NARROW_READ) is true, so it</font></tt><br><tt><font size="2">accesses the wchar_t as a char and extends that to a wchar_t.</font></tt><br><br><tt><font size="2">On a little-endian machine, this would be a no-op, but on a</font></tt><br><tt><font size="2">big-endian machine, this basically always set the character</font></tt><br><tt><font size="2">to 0.</font></tt><br><br><tt><font size="2">Now, the question is why is the NARROW_READ flag set.  It</font></tt><br><tt><font size="2">appears this is the case because the </font></tt><tt><font size="2">EL_GETCFN call that</font></tt><br><tt><font size="2">installs the callback used el_set, not el_wset (that is</font></tt><br><tt><font size="2">what triggers setting vs. clearing NARROW_READ).</font></tt><br><br><tt><font size="2">The LLDB code does *appear* to use el_wset:</font></tt><br><tt><font size="2">  el_wset(m_editline, EL_GETCFN, (EditlineGetCharCallbackType)([](</font></tt><br><tt><font size="2">                                     EditLine *editline, EditLineGetCharType *c) {</font></tt><br><tt><font size="2">            return Editline::InstanceFor(editline)->GetCharacter(c);</font></tt><br><tt><font size="2">          }));</font></tt><br><br><tt><font size="2">but that's not actually true, because of:</font></tt><br><br><tt><font size="2">#if LLDB_EDITLINE_USE_WCHAR</font></tt><br><tt><font size="2">[...]</font></tt><br><tt><font size="2">#else</font></tt><br><tt><font size="2">[...]</font></tt><br><tt><font size="2">#define el_wset el_set</font></tt><br><tt><font size="2">[...]</font></tt><br><tt><font size="2">#endif // #if LLDB_EDITLINE_USE_WCHAR</font></tt><br><br><tt><font size="2">at the top of the file.  Note that on Linux, it appears</font></tt><br><tt><font size="2">LLDB_EDITLINE_USE_WCHAR is unconditionally set to 0:</font></tt><br><br><tt><font size="2">#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) ||       \</font></tt><br><tt><font size="2">    defined(__OpenBSD__)</font></tt><br><tt><font size="2">#define LLDB_EDITLINE_USE_WCHAR 1</font></tt><br><tt><font size="2">#include <codecvt></font></tt><br><tt><font size="2">#else</font></tt><br><tt><font size="2">#define LLDB_EDITLINE_USE_WCHAR 0</font></tt><br><tt><font size="2">#endif</font></tt><br><br><tt><font size="2">So in general, it looks like the bug is that LLDB on Linux</font></tt><br><tt><font size="2">always installs the EL_GETFCN callback using el_set, which</font></tt><br><tt><font size="2">causes libedit to assume it actually takes a char *</font></tt><br><tt><font size="2">argument, but LLDB now defines the routine as taking a</font></tt><br><tt><font size="2">wchar_t * argument, which causes the character to be always</font></tt><br><tt><font size="2">read as 0 on all big-endian Linux systems.</font></tt><br><br><br><tt><font size="2">Is this enough information for you to fix the problem?</font></tt><br><tt><font size="2">If you'd like me to do more debugging, please let me know.</font></tt><br><br><tt><font size="2">Bye,</font></tt><br><tt><font size="2">Ulrich</font></tt><br><br><BR>
</body></html>