This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author yselivanov
Recipients asvetlov, christian.heimes, methane, pitrou, vstinner, yselivanov
Date 2017-12-16.00:11:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1513383091.17.0.213398074469.issue32331@psf.upfronthosting.co.za>
In-reply-to
Content
Update:

I've rewritten the PR from scratch.

1. SOCK_TYPE_MASK isn't exported on Linux.  Therefore we will not export socket.SOCK_TYPE_MASK too.

2. I've added the new socket.truetype property.

3. When a socket is created without an FD, e.g. "socket.socket(family, type, proto)", we trust that the type of the socket is correct.  It might contain extra flags on Linux, so we filter them out.

4. When a socket is created from an FD, e.g. with "socket.fromfd" or with "socket.socket(family, type, proto, FD)" we don't trust the type.  So socket.truetype will call getsockopt(SOL_SOCKET, SO_TYPE) on the FD to ensure we have the correct socket type at hand.

5. Since Linux doesn't export SOCK_TYPE_MASK I decided to hardcode it in socketmodule.c.  My reasoning:

a/ It's highly unlikely that Linux will implement 5 more new socket types anytime soon, so 0xF should last for a *very* long time.

b/ It's more likely than "a/" that they add a new flag like SOCK_CLOEXEC, in which case the "type & ~(SOCK_NONBLOCK | SOCK_CLOEXEC)" approach will fail.

So given a/ and b/ I think it's safe to just use 0xF mask on Linux.
History
Date User Action Args
2017-12-16 00:11:31yselivanovsetrecipients: + yselivanov, pitrou, vstinner, christian.heimes, asvetlov, methane
2017-12-16 00:11:31yselivanovsetmessageid: <1513383091.17.0.213398074469.issue32331@psf.upfronthosting.co.za>
2017-12-16 00:11:31yselivanovlinkissue32331 messages
2017-12-16 00:11:31yselivanovcreate