Hello,
Samuel Thibault, le Sat 21 Sep 2013 16:20:33 +0200, a écrit :
Yes. SOCK_CLOEXEC is not currently supported
Well, it is supposed to; see what I wrote in
http://news.gmane.org/find-root.php?message_id=%3C87r4d6khvr.fsf%40kepler.schwinge.homeip.net%3E.
Just to follow-up in this
Thomas Schwinge, le Thu 19 Sep 2013 15:16:30 +0200, a écrit :
Hi!
On Thu, 19 Sep 2013 02:06:27 +0200, Samuel Thibault sthiba...@debian.org
wrote:
Jens Mühlenhoff, le Thu 19 Sep 2013 01:55:24 +0200, a écrit :
I think that translates to socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0)
On Thu, 2013-09-19 at 23:12 +0200, Jens Mühlenhoff wrote:
Am 19.09.2013 05:52, schrieb Svante Signell:
In the Qt case you can make it a one-liner:
Change
if (fd != -1 || errno != EINVAL)
to
if (fd != -1 || !(errno == ENOSYS || errno == EINVAL))
as already used for accept4 on
Hi!
On Thu, 19 Sep 2013 02:06:27 +0200, Samuel Thibault sthiba...@debian.org
wrote:
Jens Mühlenhoff, le Thu 19 Sep 2013 01:55:24 +0200, a écrit :
I think that translates to socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0)
Yes. SOCK_CLOEXEC is not currently supported
Well, it is supposed to;
On Thu, 2013-09-19 at 15:16 +0200, Thomas Schwinge wrote:
Hi!
On Thu, 19 Sep 2013 02:06:27 +0200, Samuel Thibault sthiba...@debian.org
wrote:
Jens Mühlenhoff, le Thu 19 Sep 2013 01:55:24 +0200, a écrit :
I think that translates to socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0)
Yes.
Thomas Schwinge, le Thu 19 Sep 2013 15:16:30 +0200, a écrit :
On Thu, 19 Sep 2013 02:06:27 +0200, Samuel Thibault sthiba...@debian.org
wrote:
Jens Mühlenhoff, le Thu 19 Sep 2013 01:55:24 +0200, a écrit :
I think that translates to socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0)
Yes.
Am 19.09.2013 05:52, schrieb Svante Signell:
In the Qt case you can make it a one-liner:
Change
if (fd != -1 || errno != EINVAL)
to
if (fd != -1 || !(errno == ENOSYS || errno == EINVAL))
as already used for accept4 on line 122
You meant EPROTOTYPE instead of ENOSYS?
I just tried
Am 19.09.2013 23:12, schrieb Jens Mühlenhoff:
I'll report this upstream.
https://bugreports.qt-project.org/browse/QTBUG-33572
--
Mit freundlichen Grüßen
Jens Mühlenhoff
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Jens Mühlenhoff, le Thu 19 Sep 2013 01:55:24 +0200, a écrit :
is returning errno = 1073741865 which is ESPIPE?!
Err, no, it's 0x4029, i.e. _HURD_ERRNO(41), i.e. EPROTOTYPE.
I think that translates to socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0)
Yes. SOCK_CLOEXEC is not currently
Am 19.09.2013 02:06, schrieb Samuel Thibault:
Jens Mühlenhoff, le Thu 19 Sep 2013 01:55:24 +0200, a écrit :
is returning errno = 1073741865 which is ESPIPE?!
Err, no, it's 0x4029, i.e. _HURD_ERRNO(41), i.e. EPROTOTYPE.
Yes of course, I mixed up hexadecimal and decimal, it's getting late
Jens Mühlenhoff, le Thu 19 Sep 2013 02:18:28 +0200, a écrit :
Yes. SOCK_CLOEXEC is not currently supported, the TCP/IP stack thinks
the caller is inventing a new proto type numbered 4194305. You would
get the same behavior on Linux when building the application against a
recent libc, but
On Thu, 2013-09-19 at 02:33 +0200, Samuel Thibault wrote:
Jens Mühlenhoff, le Thu 19 Sep 2013 02:18:28 +0200, a écrit :
Yes. SOCK_CLOEXEC is not currently supported, the TCP/IP stack thinks
the caller is inventing a new proto type numbered 4194305. You would
get the same behavior on Linux
On Thu, 2013-09-19 at 05:38 +0200, Svante Signell wrote:
I was wondering why the Qt code is using (fd != -1 || errno != EINVAL) to
determine success?
Because Linux probably returns EINVAL instead of EPROTOTYPE in such an
error case.
You can solve this problem with a code
13 matches
Mail list logo