Mads Kiilerich <m...@kiilerich.com> added the comment: I won't claim to know more about socket error codes than what the Linux man pages says. According to them only send() can fail with ECONNRESET, even though POSIX Programmer's Manual man pages mentions many others. getpeername() is however not documented as being able to return ECONNRESET, and ENOTCONN is apparently the most appropriate error code for getpeername() both on linux (3) and posix (3p).
So: ENOTCONN from getpeername just means that the connection isn't connected. It doesn't indicate that no connection attempt has been mode, and the use of getpeername in SSLSocket.__init__ is thus not usable for checking "if the underlying socket isn’t connected yet". The wrap_socket API promises to be able to wrap both connected and unconnected sockets without being told explicit what the programmer intended. A system network socket knows if it is unused or failed, but I am not aware of any reliable cross-platform way to observe that (but that doesn't mean that none exist). The only way to reliably implement the documented wrap_socket API might thus be to maintain a flag in PySocketSockObject. Introducing a new and more explicit way of wrapping connected sockets might be a simpler and more stable solution. >From another perspective: Any user of sockets must be aware that socket >operations can fail at any time. It might thus not be a problem that >wrap_socket fails to fail, as long as the programmer knows how to catch the >failure in the next operation. From that point of view the problem is that it >is surprising and undocumented how getpeercert can fail. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13721> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
