Well I have been trying to use the fdopen approach that Sebastien proposed. I get different results. (Test fails with this method). I'm not proficient with C, but I'm guessing that using fflush with a different struct changes the expected result ?
This is the code that I'm using for testing: fdopen = libc.fdopen fdopen.restype = ctypes.POINTER(ctypes.c_void_p) fdopen.argtypes = [ctypes.c_int, ctypes.c_char_p] c_stdout_p = fdopen(1, b"w") c_stderr_p = fdopen(2, b"w") The original version segfaults, for some reason I have to pass a ctypes.POINTER to the functions, if you pass a int(ctypes.c_void_p) it breaks... Again, maybe someone with better eyes for python/C interfacing sees something that I'm missing. I attach the not working version for those who want to test other things... Cheers. Elias. On Sun, Dec 23, 2018 at 3:32 PM Sebastien Marie <sema...@online.fr> wrote: > > On Thu, Dec 20, 2018 at 10:54:28AM -0300, Elias M. Mariani wrote: > > Sorry for pinging, I forgot to add: > > A issue has been opened in upstream's github about this 16 days ago, > > no reply until now: > > https://github.com/minrk/wurlitzer/issues/23 > > > > Just to see if they have a more python-sided way of handling this. > > Personally, I found the way it is currently done to be a bit ugly, even > if it is technically correct. > > I think it could be more simple (and portable) to use a fdopen() call > with `1' as descriptor to get a FILE *stdout. It will not be exactly the > same pointer than "stdout" as the FILE struct around the descriptor will > be a new struct, but it should be as functional as "stdout". > > Something like: > > libc = ctypes.CDLL(None) > > fdopen = libc.fdopen > fdopen.restype = ctypes.c_void_p > fdopen.argtypes = [ctypes.c_int, ctypes.c_char_p] > > stdout_p = fdopen(1, "w") > stderr_p = fdopen(2, "w") > > Note that for stderr, the FILE* is normally unbuffered whereas here it > will be buffered (it is ok for stdout). > > > > The main problem is to get the length of FILE, is 152 bytes in amd64, > > > and 88 bytes in i386, no idea in other platforms, but given that this > > > lengths can change, hardcoding this numbers is ugly and bad... > > Well. usually I would agree that hardcoding is bad style. > > But I doubt the underline struct FILE will change often, I think having > it here hardcoded could be acceptable. > > It could be done at the Makefile level this way to have SIZEOF_FILE per > architecture: > > ONLY_FOR_ARCHS = amd64 i386 > > # printf("%lu\n", sizeof(FILE)); > SIZEOF_FILE-amd64 = 152 > SIZEOF_FILE-i386 = 88 > SIZEOF_FILE = ${SIZEOF_FILE-${MACHINE_ARCH}} > > SUBST_VARS += SIZEOF_FILE > > pre-configure: > ${SUBST_CMD} ${WRKSRC}/wurlitzer.py > > Thanks. > -- > Sebastien Marie
v2.tar.gz
Description: GNU Zip compressed data
