InPR 13739, Eryk Sun mentioned that the Windows implementation of os.dup() returns an inheritable fd when handling a character file. A comment in _Py_dup() makes it seem as though this is due to a belief that handles for character files cannot be made non-inheritable (which is wrong).

If you care of inherited handles on Windows, please have a look at:*https://github.com/python/cpython/pull/7827 fromhttps://bugs.python.org/issue18174*https://github.com/python/cpython/pull/7966 fromhttps://bugs.python.org/issue33966ref:https://pythondev.readthedocs.io/unstable_tests.html#windows-handlesI decided to give up because of multiprocessing race conditions. I failed to fix them.

New changeset28fca0c422b425a6be43be31add0a5328c16b0b8 by Victor Stinner (Zackery Spytz) in branch 'master':bpo-37267: Do not check for FILE_TYPE_CHAR in os.dup() on Windows (GH-14051)https://github.com/python/cpython/commit/28fca0c422b425a6be43be31add0a5328c16b0b8

According to the discussion inPR 14051: if os.dup() fails to make the new file descriptor new inheritable for a character device, the error must not be ignored. Instead, the caller is supposed to use os.dup(fd, inheritable=False).Before *this bugfix*, os.dup() didn't respect its contract: fd2 was inheritable sometimes. Now the caller is aware of such special case and so can handle it properly.

New changeset71589491ad0da27f57789b97354f6094a91e2eb3 by Victor Stinner (Miss Islington (bot)) in branch '3.7':bpo-37267: Do not check for FILE_TYPE_CHAR in os.dup() on Windows (GH-14051) (GH-14141)https://github.com/python/cpython/commit/71589491ad0da27f57789b97354f6094a91e2eb3

New changeset693945d45dfe50c843970cab3e3aa1fa3a3eddbe by Victor Stinner (Miss Islington (bot)) in branch '3.8':bpo-37267: Do not check for FILE_TYPE_CHAR in os.dup() on Windows (GH-14051) (GH-14140)https://github.com/python/cpython/commit/693945d45dfe50c843970cab3e3aa1fa3a3eddbe

Thanks Zackery Spytz as usual!

This may have caused a regression, see#37549.