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
