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
