From 0577a0cedbc5be4cd4c20ba53d3dbdac6bff9a0a Mon Sep 17 00:00:00 2001 From: Pavel Labath Date: Thu, 3 Oct 2019 08:44:33 +0000 Subject: [PATCH] "Fix" TestFileHandle.py on non-darwin platforms This test exposed a very long standing issue that the python file objects returned by the FILE* typemap were unusable on non-darwin platforms. The reason they work on darwin is that they rely on a non-standard extension to fetch the "mode" of a FILE* object. On other platforms, this code was #ifdefed out, and so we were returning an empty mode. As there's no portable way to get this information, I just change the non-darwin path to return "r+", which should permit both reading and writing operations on the object. If the underlying file descriptor turns out to be incompatible with this mode, the operating system should return EBADF (or equivalent), instead of the "file not open for XXX" error from python. llvm-svn: 373573 --- lldb/scripts/Python/python-typemaps.swig | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/lldb/scripts/Python/python-typemaps.swig b/lldb/scripts/Python/python-typemaps.swig index 7eedfdbdb8df..77ca1156ec58 100644 --- a/lldb/scripts/Python/python-typemaps.swig +++ b/lldb/scripts/Python/python-typemaps.swig @@ -406,6 +406,8 @@ bool SetNumberFromPyObject(double &number, PyObject *obj) { } %typemap(out) FILE * { + // TODO: This is gross. We should find a way to fetch the mode flags from the + // lldb_private::File object. char mode[4] = {0}; %#ifdef __APPLE__ int i = 0; @@ -420,6 +422,12 @@ bool SetNumberFromPyObject(double &number, PyObject *obj) { else // if (flags & __SRW) mode[i++] = 'a'; } +%#else + // There's no portable way to get the mode here. We just return a mode which + // permits both reads and writes and count on the operating system to return + // an error when an invalid operation is attempted. + mode[0] = 'r'; + mode[1] = '+'; %#endif using namespace lldb_private; NativeFile file($1, false);