eaducac added the comment:
Hi all,
I ran into this problem myself today with 3.3.2 and I thought I'd provide some
more detail on what's going on. As has been described, prior to VC11,
fileno(stdin) returned -2 in applications with no console, so is_valid_fd() was
properly rejecting it and the standard streams were being set to None. With
VC11, it now returns 0, and the NT handle that underlies the FILE object
associated with file descriptor 0 is -2. The problem is that -2 is a
pseudo-handle representing the current thread. dup() is simply a wrapper around
the Windows API function DuplicateHandle(), so when dup() is called on file
descriptor 0, it returns success because DuplicateHandle() is successfully
creating a new handle referring to the current thread. It's not until the call
to fstat() in check_fd() much later that the CRT realizes it's not dealing with
a file.
I see in Mercurial that 3.3.4 and 3.4 that the is_valid_fd() code hasn't been
changed. This is definitely a Microsoft bug, but if (as it sounds) they're not
going to be able to fix it anytime soon, I think it would be ideal to have a
change for this in Python. Replacing this with check_fd() would fix it, or if
you don't want to rely on fstat(), some Windows-specific code using
GetStdHandle():
#ifdef MS_WINDOWS
if (!is_valid_fd(fd) || GetStdHandle(STD_INPUT_HANDLE) == NULL) {
#else
if (!is_valid_fd(fd)) {
#endif
That would have to be repeated for stdout and stderr using
GetStdHandle(STD_OUTPUT_HANDLE) and GetStdHandle(STD_ERROR_HANDLE), as those
descriptors have the same problem.
----------
nosy: +eaducac
versions: +Python 3.3
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue17797>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
