[Python-Dev] test_urllibnet failing on Windows

[Guido van Rossum]

> I'm not familiar with this test.

Me neither, but Brett C should be. :-)

> In a debug build:
> 
> """
> C:\Code\python\PCbuild>python_d ../lib/test/test_urllibnet.py
> testURLread (__main__.URLTimeoutTest) ... ok
> test_bad_address (__main__.urlopenNetworkTests) ... ok
> test_basic (__main__.urlopenNetworkTests) ... ok
> test_fileno (__main__.urlopenNetworkTests) ...
> """
> 
> and there it dies with an assertion error in the bowels of Microsoft's
> fdopen.c.  That's called by Python's posix_fdopen, here:
> 
> 	fp = fdopen(fd, mode);
> 
> At this point, fd is 436.  MS's fdopen is unhappy because only 32
> handles actually exist at this point, and 436 is bigger than that.
> In the release build, the MS assert doesn't (of course) trigger;
> instead, that 436 >= 32 causes MS's fdopen to return NULL.

The test assumes that the fileno() from a socket object can be passed
to os.fdopen().  That works on Unix.  But on Windows it cannot, the
small ints used to refer to open files are chosen from a different
(though potentially overlapping) space than the small ints used to
refer to open sockets, and the two cannot be mixed.

So the test should be disabled on Windows.

I don't know if we can protect os.fdopen() from crashing when passed
an out of range number.

--Guido van Rossum (home page: http://www.python.org/~guido/)