DragonFlyBSD

`osockaddr` predates the introduction of the sa_len
field in `struct sockaddr`. The family has moved to
the second field in the structure, but `talk` didn't
account for this when it constructs a `sockaddr_in`
to send data to another system.

The failure case was kind of odd: one could `talk`
to a user on, say, a Linux machine, the remote user
could respond, and things would work as expected.
However, the inverse case, where a user on Linux
tried to `talk` to a user on Dragonfly failed: the
talk announcement would be made, but an attempt to
respond would fail with a protocol error since the
`sin_family` field would be zero.