Date: Fri, 27 Oct 2000 18:11:51 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Brian Somers <brian@Awfulhak.org> Cc: kargl@apl.washington.edu, freebsd-current@FreeBSD.ORG Subject: Re: more endian.h breakage; patch included. Message-ID: <Pine.BSF.4.21.0010271755210.47277-100000@besplex.bde.org> In-Reply-To: <200010181846.e9IIkZY00872@hak.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 18 Oct 2000, Brian Somers wrote:
> > On Mon, 16 Oct 2000, Brian Somers wrote:
> > > ntohl() & ntonl() were previously wrong to return u_long.
> >
> > Not wrong. They have always been documented to return u_long.
>
> But if sizeof(u_long) != 4, this is wrong.
It's not best, but not wrong, since u_long is large enough to hold
all values of interest and the interfaces don't involve any pointers.
[... lots deleted]
> I think the best way forward is to prototype things in terms of
> in_addr_t and in_port_t and to leave them as inlines for __GNUC__
> (I don't know where other compilers are supposed to get this
> functionality).
I agree.
> I think we should *not* include sys/types.h and should leave all of
> the sys/types.h additions that I've done to files that include
> sys/wait.h, but this idea conflicts with all other endian.h files
> (both ours and {Net,Open}BSDs), and is probably wrong in that
> requiring sys/anything for machine/anything is probably not too good.
Just define in_addr_t and in_port_t in terms of basic types, like we
already do for int32_t, etc.
> Maybe the NetBSD way of moving machine/endian.h to sys/endian.h and
> having machine/endian.h as a simple ``#include <sys/endian.h>'' is
> the cleanest solution....
Except this isn't backwards compatible and there is no reason to put it
in <sys>.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0010271755210.47277-100000>