Sounds good. I will test this out once that patch goes in. And yea, I would prefer to remove the codepage stuff for now, and we can re-consider adding it back if/when someone actually needs it. Then we can discuss some other options like a preprocessor define that enables setting the codepage, or a command line switch, etc.
On Wed, Mar 9, 2016 at 2:27 PM Cameron <[email protected]> wrote: > cameron314 added a comment. > > Yes, if lldb.exe crashes or otherwise exits without returning to main, > then the codepage will stay set in the current console. The latter can be > fixed with a static object destructor, but not the former. I don't think > this would be a practical problem, since very few console applications > depend on the codepage in the first place (those that do tend to set it > manually when they start). The setting isn't permanent, either, it's only > for the current console window until it closes (or is reset by somebody > else). And it doesn't affect the bytes input/output by any programs, only > the way the console interprets those bytes. I'd say the impact of changing > the codepage without changing it back is very low. > > That part of the patch is not quite as important -- without it UTF-8 I/O > is broken, but it's already broken anyway unless the user has taken > explicit steps to reconfigure Window's console system to support Unicode > character display (which requires fiddling in the registry and rebooting). > No one I know has done this. I can remove it from the patch if you think > it's too risky. > > We're using both liblldb and lldb.exe, though mostly liblldb. No Python > bindings as of now. > > The patch for LLVM has been accepted, I'm waiting for someone to commit it > when they have a moment. I'll rebase this one on the tip again afterwards. > > > http://reviews.llvm.org/D17107 > > > >
_______________________________________________ lldb-commits mailing list [email protected] http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
