From owner-freebsd-arch  Sat Sep  8  5:37:34 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62])
	by hub.freebsd.org (Postfix) with ESMTP id 411B737B405
	for <arch@FreeBSD.ORG>; Sat,  8 Sep 2001 05:37:32 -0700 (PDT)
Received: from mindspring.com (dialup-209.245.142.217.Dial1.SanJose1.Level3.net [209.245.142.217])
	by snipe.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f88CbLW01492;
	Sat, 8 Sep 2001 05:37:25 -0700 (PDT)
Message-ID: <3B9A112D.5909ECE@mindspring.com>
Date: Sat, 08 Sep 2001 05:38:05 -0700
From: Terry Lambert <tlambert2@mindspring.com>
Reply-To: tlambert2@mindspring.com
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: karels@BSDI.COM
Cc: Bill Fenner <fenner@research.att.com>, arch@FreeBSD.ORG
Subject: Re: Causing <netinet/in.h> to depend on <sys/socket.h>
References: <200109072110.f87LADX15133@redrock.eng.bsdi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

Mike Karels wrote:
> >               Inclusion of the <netinet/in.h> header may also make
> >               visible all symbols from <inttypes.h> and <sys/socket.h>.
> 
> I haven't seen that version of the networking stuff yet.  However, if
> you are solving the problem I think you are, types like sa_family_t,
> I can tell you what we do in BSD/OS: we created a <sys/sockettypes.h>,
> and include it from both <sys/socket.h> and <netinet/in.h>.

This is MUCH cleaner; however, it's still really, really
ugly, in that it makes one include file include another,
and thus crams a whole bunch of unexpected crap into the
implementation space.

I haven't seen where the sockaddr_storage type is used, yet
(no one has posted anything), but it seems to me that if,
when it is used, it is used as an opaque pointer type, where
possible, then this avoids the need to pollute the namespace
unless someone is referencing members of the structure, which
means they are actually using it, which means that they can
darn well include a header file to get the non-opaque version
of the structure declaration so that they can instance the
thing.

-- Terry

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