Re: lib/45564: 2nd socket created by socketpair(2) is not connected to 1st socket.

["NARUSE, Yui" <naruse%airemix.jp@localhost>]

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

From: "NARUSE, Yui" <naruse%airemix.jp@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: lib/45564: 2nd socket created by socketpair(2) is not connected
 to 1st socket.
Date: Sat, 5 Nov 2011 16:10:55 +0900

 2011/11/5 Matthew Mondor <mm_lists%pulsar-zone.net@localhost>:
 > The following reply was made to PR lib/45564; it has been noted by GNATS.
 >
 > From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:
 > Subject: Re: lib/45564: 2nd socket created by socketpair(2) is not connec=
 ted
 > =A0to 1st socket.
 > Date: Fri, 4 Nov 2011 12:59:48 -0400
 >
 > =A0On Thu, =A03 Nov 2011 18:05:00 +0000 (UTC)
 > =A0naruse%airemix.jp@localhost wrote:
 >
 > =A0> getpeername: Socket is not connected
 >
 > =A0Does this still happen if you remove SOCK_CLOEXEC from the protocol
 > =A0argument to socketpair(2)? =A0If it no longer occurs without the
 > =A0SOCK_CLOEXEC, fcntl(2) could be used to later enable close-on-exec
 > =A0instead.
 
 No, it doesn't happen without SOCK_CLOEXEC.
 
 > =A0If removing SOCK_CLOEXEC doesn't help, do write/read work while
 > =A0getpeername fails (it seems odd to me to call getpeername(2) on a
 > =A0socketpair)?
 
 Other operations like send also fails.
 Of course it works for first one.
 
 --=20
 NARUSE, Yui =A0<naruse%airemix.jp@localhost>