On 8/20/19 2:29 PM, Bruno Haible wrote:
> Eric Blake wrote:
>> +#if SOCK_CLOEXEC
>> + if (flags & SOCK_NONBLOCK)
>
> Why '#if SOCK_CLOEXEC'?
> Why not '#if SOCK_NONBLOCK'?
Because I made a typo. Thanks for spotting it; will fix shortly.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Eric Blake wrote:
> Hmm, I guess it would be better to make the accept4 module depend on
> nonblocking
I would not like this. The 'nonblocking' module is quite intrusive
(it hooks into many stdio functions, from 'getchar' to 'fprintf').
Few applications use nonblocking file, pipe, or sockets. The
Eric Blake wrote:
> #if HAVE_ACCEPT4
>
> Aha - there's the bug.
>
> Commit e597d4b8 changed from AC_CHECK_FUNCS_ONCE (defines HAVE_ACCEPT4)
> to AC_CHECK_DECLS (defines HAVE_DECL_ACCEPT4), but failed to update the
> .c file. I'll push the obvious fix.
Indeed. My mistake, sorry.
Bruno
Eric Blake wrote:
> +#if SOCK_CLOEXEC
> + if (flags & SOCK_NONBLOCK)
Why '#if SOCK_CLOEXEC'?
Why not '#if SOCK_NONBLOCK'?
Bruno
On Tue, Aug 20, 2019 at 11:37:27AM -0500, Eric Blake wrote:
> +#if SOCK_CLOEXEC
> + if (flags & SOCK_NONBLOCK)
> +{
> + int fcntl_flags;
> +
> + if ((fcntl_flags = fcntl (fd, F_GETFL, 0)) < 0
> + || fcntl (fd, F_SETFL, fcntl_flags | O_NONBLOCK) == -1)
Can't this call set_no
On 8/20/19 11:37 AM, Eric Blake wrote:
> Ideally, we would improve our replacement to define a
> replacement SOCK_NONBLOCK on all platforms, and teach socket() to
> honor it as well; but that's a bigger task. In the meantime, if the
> platform already has SOCK_NONBLOCK, we should honor it when do
Ideally, we would improve our replacement to define a
replacement SOCK_NONBLOCK on all platforms, and teach socket() to
honor it as well; but that's a bigger task. In the meantime, if the
platform already has SOCK_NONBLOCK, we should honor it when doing a
fallback.
* lib/accept4.c (accept4): If
On 8/20/19 10:27 AM, Richard W.M. Jones wrote:
> First of all I'm using Linux 5.0.17 & glibc-2.29-15 so as far as I'm
> aware accept4 exists and fully works and gnulib shouldn't be replacing
> it at all. I don't understand why it's being replaced.
>
I think I'm reproducing your setup (Fedora 30)
* Richard W. M. Jones:
> On Tue, Aug 20, 2019 at 05:37:58PM +0200, Florian Weimer wrote:
>> * Richard W. M. Jones:
>>
>> > As for why accept4 is being replaced at all, the only reference to it
>> > in config.log is:
>> >
>> > configure:25630: checking whether accept4 is declared
>> > configur
On Tue, Aug 20, 2019 at 05:37:58PM +0200, Florian Weimer wrote:
> * Richard W. M. Jones:
>
> > As for why accept4 is being replaced at all, the only reference to it
> > in config.log is:
> >
> > configure:25630: checking whether accept4 is declared
> > configure:25630: gcc -c -O2 -g -pipe -Wal
* Richard W. M. Jones:
> As for why accept4 is being replaced at all, the only reference to it
> in config.log is:
>
> configure:25630: checking whether accept4 is declared
> configure:25630: gcc -c -O2 -g -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
First of all I'm using Linux 5.0.17 & glibc-2.29-15 so as far as I'm
aware accept4 exists and fully works and gnulib shouldn't be replacing
it at all. I don't understand why it's being replaced.
But given that, in libguestfs we call:
r = accept4 (console_sock, NULL, NULL, SOCK_NONBLOCK|SOCK_CL
12 matches
Mail list logo
