[Lldb-commits] Fix a bug with order of operations

[Zachary Turner]

I accidentally reversed the conditional on this patch.  A corrected patch
is attached.




On Wed, Jul 16, 2014 at 1:42 PM, Zachary Turner <zturner at google.com> wrote:

> Hi Greg,
>
> Looks like a simple bug where it should have been "a | b | (c ? 0 : d)"
> instead of "a | b | c ? 0 : d".  Rather than rely on order of operations,
> which I always find confusing, I opted to just move this out into explicit
> initialization of the flags.
>
> Let me know if the new code matches your original intent.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20140717/62e6833c/attachment.html>
-------------- next part --------------
diff --git a/source/Interpreter/ScriptInterpreterPython.cpp b/source/Interpreter/ScriptInterpreterPython.cpp
index 0467914..ac4b29f 100644
--- a/source/Interpreter/ScriptInterpreterPython.cpp
+++ b/source/Interpreter/ScriptInterpreterPython.cpp
@@ -2445,11 +2445,8 @@ ScriptInterpreterPython::RunScriptBasedCommand(const char* impl_function,
     std::string err_msg;
     
     {
-        uint16_t entry_flags = Locker::AcquireLock | Locker::InitSession;
-        if (!cmd_retobj.GetInteractive())
-            entry_flags |= Locker::NoSTDIN;
         Locker py_lock(this,
-                       entry_flags,
+                       Locker::AcquireLock | Locker::InitSession | cmd_retobj.GetInteractive() ? 0 : Locker::NoSTDIN,
                        Locker::FreeLock    | Locker::TearDownSession);
         
         SynchronicityHandler synch_handler(debugger_sp,