-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The Linux man page for connect(2) currently says:

  Connectionless sockets may dissolve the association by connecting to
  an address with the sa_family member of sockaddr set to AF_UNSPEC.


No such wording is in the POSIX definition which only says

  If  address is a null address for the protocol, the socket’s peer
  address shall be reset.


This is not the same but seems to be what Linux implements.


The problem is that I tried to reuse a socket which has been associated
with an IPv6 address to later connect to an IPv4 address.  This is part
of the getaddrinfo implementation and an effort to make it more
efficient.  strace's output  looks like this:

connect(3, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6,
"2001:11b8:1:0:207:e94f:ee7c:4b72", &sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)

connect(3, {sa_family=AF_UNSPEC,
sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 28) = 0

connect(3, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.1.72")}, 16) = 0


I.e., despite what the man page says, the second connect only reset the
address, as required by the POSIX spec.  It did not reset the address
family of the socket.


What I ideally would like to see is what the Linux man page says.  I.e.,
if the .sa_family field is AF_UNSPEC all, the address and address
family, is reset.  Otherwise only the address association itself is reset.

Is this functionality which got lost over time?  Or is the man page
wrong and this never was the case?  Is this a worthwhile change?

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFG8M+52ijCOnn/RHQRAnTEAJ0Z/DrTkcCjpbybB5lqDad9Z0MbZwCeLZOh
u/mNfxV7uDjRsSuOj4YwuIg=
=FO70
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to