GNOME Bugzilla – Bug 708266
fix error code checks when SOCK_CLOEXEC is defined but not supported
Last modified: 2013-09-24 13:02:51 UTC
Created attachment 255139 [details] [review] add check for EPROTOTYPE return code for socket() Hi, On GNU/Hurd SOCK_CLOEXEC is defined in header files, but only supported for accept4, not yet for socket or socketpair. The attached patch adds the error code EPROTOTYPE returned from socket(), as specified by POSIX_1003.1, http://pubs.opengroup.org/onlinepubs/009695399/functions/socket.html
EPROTOTYPE as a return value in this case looks non-spec-compliant. That seems more like if I tried to open an AF_UNIX socket with the protocol 'tcp' or something...
From the POSIX page: int socket(int domain, int type, int protocol); [EPROTOTYPE] The socket type is not supported by the protocol. I think the error code is correct, even if Linux returns EINVAL. Additionally, SOCK_CLOEXEC is not POSIX. From the socket(2) man-page: The SOCK_NONBLOCK and SOCK_CLOEXEC flags are Linux-specific. See also the corresponding bug for dbus, already committed upstream: https://bugs.freedesktop.org/show_bug.cgi?id=69073
ah, so, the Hurd has SOCK_CLOEXEC in its headers because it's using glibc, but the kernel knows nothing about it, so when you pass SOCK_STREAM | SOCK_CLOEXEC, it doesn't see it as "SOCK_STREAM and an unknown option", it sees it as "mystery socket type 0x80001" and says "I don't support that socket type". So yeah, the patch is correct. Can you resubmit it as a git-format-patch style patch with a proper author and commit message? https://wiki.gnome.org/Git/Developers#Contributing_patches
Created attachment 255229 [details] [review] updated patch git-generated patch
Attached is a git patch (hopefully correct). (I tried reply by email, but that did not work. It does for bugzilla-daemob@freedesktop.org)
Comment on attachment 255229 [details] [review] updated patch ok. I'll commit it post-freeze
committed to master and glib-2-38