[Lldb-commits] [lldb] r303907 - Fix bug #28898

[Pavel Labath via lldb-commits]

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 <christos at zoulas.com> wrote:
>
> On May 31, 10:31am, labath at 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