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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
