[Lldb-commits] [PATCH] D69532: [LLDB][PythonFile] fix dangerous borrow semantics on python2

Tue Oct 29 11:23:14 PDT 2019

lawrence_danna added a comment.

In D69532#1724806 <https://reviews.llvm.org/D69532#1724806>, @labath wrote:

> So, if I understand correctly. The problem here is the final call to `fflush`, which can end up referencing a closed FILE*. Can we just not call `fflush` then?

Hrm, maybe.  I'll try it and see if anything breaks.

> It shouldn't be really needed -- if everything goes through the same FILE* object, the C library will make sure the writes are available to anyone who tries to read through that object.
>  I don't buy the argument that holding onto a FD-backed object after the FD has been closed is somehow "safer" than holding onto a FILE*. They both produce undefined behavior,

But this is a fundamental difference between python and C++.   In C++ there's only one level of UB.   If you do something illegal, your program can crash, demons come out of your nose, whatever.   In python, unless you're using something like ctypes, UB means your program misbehaves, but should never mean that the interpreter crashes.   An interpreter crash in python is not the moral equivalent of a segfault in C++, it's the equivalent of a kernel panic.   If unprivileged C++ code crashes the kernel, that's a bug in the kernel, whether UB was involved or not.   If a non-ctypes python program crashes the interpreter, that's a bug in Python or some loadable module, no matter how incorrect the python program was.

The other aspect here is that it is reasonable to ask a python programmer not to use a closed file.    I don't  think it is ever safe to ask a python programmer to ensure that reference counts get decremented in a particular order.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69532/new/

https://reviews.llvm.org/D69532