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

Wed Oct 30 04:04:28 PDT 2019

labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

In D69532#1725772 <https://reviews.llvm.org/D69532#1725772>, @lawrence_danna wrote:

> > 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.

Yes, I get that. What I was trying to say that using a fd-based python file after it has been closed introduces exactly the same level of UB as for a FILE*-based one. I mean, for all you know, the fd might be recycled to point to /dev/sda, and writing to it can make your whole system unbootable.

The difference was that in the FILE* case the mere act of closing constituted a "use", while for a fd file we just happily did nothing. Not fflushing makes this aspect of the two implementations equal. It is true that this introduces some potential difference in behavior as a FILE* involves userspace buffers, whereas for an fd everything would go to the kernel straight away (at least on posix systems). However, cloning a bunch of FILE*s would introduce other kinds of inconsistencies, so I think this is a better tradeoff.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69532