[Guido] > The test assumes that the fileno() from a socket object can be passed > to os.fdopen(). Yup, Jeremy figured that out here. I have a patch waiting to go, but SF isn't cooperating. > 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. Just so. > 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. This is an issue only in the MSVC debug build. The release-build MS libraries *still* explicitly check for out-of-range, and arrange for an error return when it is out of range. I really don't understand why they're asserting in-range in their debug build libraries, because nothing in *their* code assumes the fd is in-range -- their code is defensive enough in the release build that nothing bad will happen even when it is out of range.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4