Re: kern/54650: Calling accept() with a non-blocking listening socket, returns a non-blocking connected socket, which is incorrect behaviour

[Jason Thorpe <thorpej%me.com@localhost>]

The following reply was made to PR kern/54650; it has been noted by GNATS.

From: Jason Thorpe <thorpej%me.com@localhost>
To: Sad Clouds <cryintothebluesky%gmail.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost,
 Martin Husemann <martin%duskware.de@localhost>,
 kern-bug-people%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/54650: Calling accept() with a non-blocking listening
 socket, returns a non-blocking connected socket, which is incorrect behaviour
Date: Sun, 27 Oct 2019 06:20:26 -0700

 > On Oct 27, 2019, at 12:59 AM, Sad Clouds <cryintothebluesky%gmail.com@localhost> =
 wrote:
 >=20
 > On Sun, 27 Oct 2019 07:30:02 +0000 (UTC)
 > Martin Husemann <martin%duskware.de@localhost> wrote:
 >=20
 >> I think it is also documented in accept(4):
 >>=20
 >> 	... creates a new socket with the same
 >>      properties of s and allocates a new file descriptor for the
 >> socket.=20
 >> Where I read "same properties" as including the socket options.
 >>=20
 >> Martin
 >>=20
 
 There is a lot less text in the SUSv4 description of accept(2):
 
 <quote>
 The accept() function shall extract the first connection on the queue of =
 pending connections, create a new socket with the same socket type =
 protocol and address family as the specified socket, and allocate a new =
 file descriptor for that socket. The file descriptor shall be allocated =
 as described in File Descriptor Allocation.
 </quote>
 
 It does not explicitly allow the historic BSD behavior, nor does it =
 explicitly forbid it.
 
 >=20
 > OK, if that is the case, then please close this bug. Just had a look =
 at
 > OpenBSD accept() man page and it is much more clear there:
 >=20
 > "The accept() call extracts the first connection request on the queue =
 of
 > pending connections, creates a new socket with the same non-blocking
 > I/O mode as s, and allocates a new file descriptor for the socket with
 > the close-on-exec flag clear."
 >=20
 > The way Linux behaves makes more sense to me, just because the
 > listening socket is non-blocking, does not mean I want all the =
 accepted
 > sockets to be also non-blocking. But it looks like another portability
 > issue we have to deal with on different platforms.=20
 
 -- thorpej