I have some code that uses ctypes to try to determine if the file pointed to by sys.stdout
is actually stdout
. I know that on any POSIX-compliant system, and even on Windows, it should be safe to assume this is true if sys.stdout.fileno() == 1
, so my question is not how to do this in general.
In my code (which is already using ctypes for something unrelated to my question) I carelessly had something like:
libc = ctypes.CDLL(ctypes.util.find_library('c'))
real_stdout = libc.fileno(ctypes.c_void_p.in_dll(libc, 'stdout'))
if sys.stdout.fileno() == real_stdout:
...
This works perfectly fine on Linux, so I didn't really think about it much. It looked nicer and more readable than hard-coding 1
as the file descriptor. But I found a few days later that my code wasn't working on OSX.
It turns outs OSX's libc doesn't export any symbol called 'stdout'. Instead its stdio.h has stdout defined as:
#define stdout __stdoutp
If I change my code to c_void_p.in_dll(libc, '__stdoutp')
my code works as expected, but of course that's OSX-only. Windows, it turns out, has a similar issue (at least if using MSVC).
I will probably just change my code to use 1
, but my question still stands, out of curiosity, if there's a cross-platform way to get the stdio
pointer (and likewise stdin
and stderr
) without assuming that it's using the POSIX-compliant descriptor?
As so often when it comes to C, if you want compatibility, you'll have to go and look in the relevant standard. Since you mention windows, I guess you're not actually wanting the POSIX standard, but rather the C one.
C99 section 7,19,1 defines stdout to be a macro, and thus not a variable. That means there's no way you can rely on finding it using dlsym (which I assume in_dll uses). The actual expression could just as well be a function call or a fixed address. Perhaps not very likely, but it is possible...
As said in the comments, the fileno function is in turn defined by POSIX, not by C. C has no concept of file descriptors. I think you're better off assuming POSIX and just checking for the value 1, which it specifies.
If you're simply interested in making things work, rather than strict standards adherence (like me), you can find the "real" name of stdout by writing a simple C snippet:
echo -e '#include <stdio.h>\nFILE* mystdout = stdout;' > test.c
cpp test.c | tail
Gives you the output:
FILE* mystdout = __stdoutp;
This means that you also need to try ctypes.c_void_p.in_dll(libc, '__stdoutp')
to cover the case of darwin.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With