From owner-freebsd-arch  Sat Sep  8 13:22: 4 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
	by hub.freebsd.org (Postfix) with ESMTP id F331637B406
	for <arch@freebsd.org>; Sat,  8 Sep 2001 13:22:01 -0700 (PDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id 4E92D4CE3E; Sat,  8 Sep 2001 16:22:01 -0400 (EDT)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA27824;
	Sat, 8 Sep 2001 16:22:00 -0400 (EDT)
From: Bill Fenner <fenner@research.att.com>
Received: (from fenner@localhost)
	by windsor.research.att.com (8.8.8+Sun/8.8.5) id NAA13321;
	Sat, 8 Sep 2001 13:22:00 -0700 (PDT)
Message-Id: <200109082022.NAA13321@windsor.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: jlemon@flugsvamp.com
Subject: Re: Causing <netinet/in.h> to depend on <sys/socket.h>
Cc: arch@freebsd.org
References:  <200109072125.OAA25298@windsor.research.att.com> <3B9A134D.3B31C443@mindspring.com> <200109081858.LAA12165@windsor.research.att.com> <20010908141005.R20137@prism.flugsvamp.com>
Date: Sat, 8 Sep 2001 13:21:59 -0700
Versions: dmail (solaris) 2.2j/makemail 2.9b
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG


>It seems that the real problem here is that sockaddr_storage is supposed
>to be protocol-neutral (used for appletalk, IPX, etc), but what your 
>code really wants is IP-specific sockaddr_storage.

Well, sockaddr_storage was introduced to support IPv6; it was defined
to be "at least large enough to accommodate sockaddr_in and sockaddr_in6
and possibly other protocol specific socket addresses too." [RFC 2553
section 3.10].  I guess the "and possibly other..." part is what's not
working out, especially since IEEE Std 1003.1-200x gets rid of the "possibly"
part.

The advantage of sockaddr_storage is that it's already standard, in
widespread use, and was defined for exactly this purpose.

  Bill

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message