Thanks for confirming that. I have created <https://reviews.llvm.org/D47625> which tries to implement this. Could you take quick look at that? There is one particular question about EL_CLIENTDATA that I would like to hear your thoughts on. On Thu, 31 May 2018 at 12:47, Christos Zoulas <chris...@zoulas.com> wrote: > > On May 31, 10:31am, lab...@google.com (Pavel Labath) wrote: > -- Subject: Re: [Lldb-commits] [lldb] r303907 - Fix bug #28898 > > | I hate to resurrect an old thread, but there has been a new spurt of > | this discussion about this patch here > | <https://reviews.llvm.org/rL303907>. > | > | I think I have an idea on how to improve things slightly for us here, > | but as I know very little about this issue, I'd like someone to take a > | look at this first. > | > | Christos, can you check whether my proposal makes sense to you? I am > | including it in this email for your convenience: > | > | > | === > | I've re-read the last years discussions, and I think I have an idea on > | how to improve the situation here somewhat. The way I understand it, > | we have three scenarios to worry about: > | > | 1. old-libedit --enable-widec > | - el_gets -> narrow_read_function > | - el_wgets -> wide_read_function > | 2. new-libedit --enable-widec > | - el_gets -> wide_read_function > | - el_wgets -> wide_read_function > | 3. libedit --disable-widec > | - I don't actually know what happens here but my proposal does not > | change our behavior in this case. > | > | As I understand it, the problem is that we are not able to distinguish > | between (1) and (2) and build time, so we have to just pick one and > | hope it works. This means we work correctly for (1), we fail for (2) > | and something unknown happens for (3). > | > | However, we **are** able to distinguish between (1+2) and (3) at build > | time (just search for `el_wgets` symbol). And, if I understand it > | correctly, when we use el_wgets and friends we are always correct, no > | matter the libedit version. This would mean are always correct for > | both (1) **and** (2), while the situation remains unchanged for (3). > | This should be a strict improvement over status quo. > > I think that you are right. Nevertheless what you propose it should > be an improvement over the status quo. > > christos _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r303907 - Fix bug #28898
Pavel Labath via lldb-commits Fri, 01 Jun 2018 04:18:49 -0700
- Re: [Lldb-commits] [lldb] r303907 - Fix b... Pavel Labath via lldb-commits
- Re: [Lldb-commits] [lldb] r303907 - ... Christos Zoulas via lldb-commits
- Re: [Lldb-commits] [lldb] r30390... Pavel Labath via lldb-commits