After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 708266 - fix error code checks when SOCK_CLOEXEC is defined but not supported
fix error code checks when SOCK_CLOEXEC is defined but not supported
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
2.37.x
Other GNU Hurd
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2013-09-17 21:40 UTC by Svante Signell
Modified: 2013-09-24 13:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
add check for EPROTOTYPE return code for socket() (298 bytes, patch)
2013-09-17 21:40 UTC, Svante Signell
none Details | Review
updated patch (748 bytes, patch)
2013-09-18 14:57 UTC, Svante Signell
committed Details | Review

Description Svante Signell 2013-09-17 21:40:13 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
Comment 1 Allison Karlitskaya (desrt) 2013-09-18 02:01:16 UTC
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...
Comment 2 Svante Signell 2013-09-18 06:28:18 UTC
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
Comment 3 Dan Winship 2013-09-18 13:42:53 UTC
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
Comment 4 Svante Signell 2013-09-18 14:57:19 UTC
Created attachment 255229 [details] [review]
updated patch

git-generated patch
Comment 5 Svante Signell 2013-09-18 14:59:22 UTC
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 6 Dan Winship 2013-09-18 16:25:15 UTC
Comment on attachment 255229 [details] [review]
updated patch

ok. I'll commit it post-freeze
Comment 7 Dan Winship 2013-09-24 13:02:48 UTC
committed to master and glib-2-38