"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

1 files changed, 8 insertions, 0 deletions

diff --git a/lldb/scripts/Python/python-typemaps.swig b/lldb/scripts/Python/python-typemaps.swig
index 7eedfdbdb8d..77ca1156ec5 100644
--- a/lldb/scripts/Python/python-typemaps.swig
+++ b/lldb/scripts/Python/python-typemaps.swig
@@ -406,6 +406,8 @@ bool SetNumberFromPyObject<double>(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>(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);