[Python-Dev] Re: [Python-checkins] python/dist/src/Modules socketmodule.c, 1.298, 1.299 (original) (raw)

Dave Cole djc at object-craft.com.au
Fri Aug 20 07:06:21 CEST 2004

Andrew McNamara wrote:

Patch #1003700: Add socketpair function to socket module.

The docstring (below) states the arguments are the same as socket(). However, in sockinitobj() line 2496, the family is initialized to AFINET. I think the #if defined(AFUNIX) code above should be removed and family should be initialized to AFINET. I talked Dave into this - AFUNIX is typically the only address family that is valid for socketpair(). Using AFINET under linux and OS X results in EOPNOTSUPP.

I wondered about the AF_UNIX/AF_INET thing. When looking through the code I noticed that all references to AF_UNIX were #ifdef enclosed. I decided to allow for the possibility of socketpair() support on a platform that supports AF_INET but not AF_UNIX (no idea if such a thing exists). The other alternative could have been to conditional include socketpair() only if both AF_UNIX and HAVE_SOCKETPAIR are defined.

Another thing to consider is the prior art in the form of eunuchs. The implementation of socketpair() in eunuchs defaults to AF_UNIX. Code using eunuchs is probably assuming AF_UNIX - not a bad assumption really.

Would a change to the documentation and docstring be sufficient it it explained that the default family is AF_UNIX if defined for the platform, AF_INET otherwise?

I don't think the #ifdef SIGPIPE code is correct. If the user installed a signal handler calling signal() will remove it. I think the call to signal() should be removed.

I agree, but I think that was copied verbatim from elsewhere in socketmodule.c, so it was left with the aim of being bug for bug compatible with socket.socket().

Indeed. I was not going to change something as fundamental as the existing signal handling. The onyl sensible thing to do was to copy the behaviour already in place when you create a socket the "normal" way.

-- http://www.object-craft.com.au

More information about the Python-Dev mailing list