The Frontpanel ReadFromPipeOut API call uses quite an unusual parameter passing arrangement (for Python; it is normal for C). A string is passed in and the content is modified. In Python strings are immutable (they may not be modified once created) so this will cause problems elsewhere.
For example, the Python intepreter applies a string pool optimisation, so two strings with the same content will actually be the same object:
[CODE]>>> x=“test”
y=“test”
id(x), id(y)
(1077488064, 1077488064)[/CODE]
This works fine as long as strings are not modified, but if the output of ReadFromPipeOut is stored somewhere, an aliasing problem could be created and the string overwritten. In dictionary objects, which rely on the immutability of keys, the data structure could be corrupted.
From a glance at the code, it looks like ReadFromPipeOut calls PyString_AsString and the resulting pointer passed to the C API okCUsbFrontPanel_ReadFromPipeOut, which writes the data into the pointer. The Python documentation says about this pointer:
— Begin quote from ____
The data must not be modified in any way, unless the string was just created using PyString_FromStringAndSize(NULL, size)
— End quote
Is this really what is happening or am I misunderstanding something? If so, could it please be fixed? The normal Python way to return the contents of a pipe/file-like object is to return a string from the read() call. This looks like it could be done without substantial modification, by using PyString_FromStringAndSize to create a new string, but I don’t have the source or SWIG interface file so I can’t easily do this.
Update: The cstring.i SWIG library has some useful functions for achieving this and the Python documentation describes why modifying immutable objects is unwise.