Date: Wed, 18 Oct 2000 11:46:35 -0700 From: Brian Somers <brian@Awfulhak.org> To: Bruce Evans <bde@zeta.org.au> Cc: Brian Somers <brian@Awfulhak.org>, kargl@apl.washington.edu, freebsd-current@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: more endian.h breakage; patch included. Message-ID: <200010181846.e9IIkZY00872@hak.lan.Awfulhak.org> In-Reply-To: Message from Bruce Evans <bde@zeta.org.au> of "Mon, 16 Oct 2000 19:44:33 %2B1100." <Pine.BSF.4.21.0010161936340.2691-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, 16 Oct 2000, Brian Somers wrote:
>
> > > On Sun, 15 Oct 2000, Steven G. Kargl wrote:
> > >
> > > > There is another patch needed in libdialog.
> > >
> > > No patches are needed in applications; endian.h should be unbroken.
> >
> > In what way ?
>
> endian.h shouldn't depend on <sys/types.h> or include <sys/types.h> and
> its associated namespace pollution. It never did before.
>
> > 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.
> > They now return uint32_t (which requires sys/types.h).
>
> In NetBSD and in FreeBSD for all arches except i386's they return
> in_addr_t which happens to be u_int32_t.
For all these arches, machine/endian.h also includes sys/types.h :-(
> > They *could* be changed to return u_int32_t, but this doesn't seem to
> > be the best way forward.
>
> I agree that it's not the best way forward, but u_int32_t is traditional
> namespace pollution in <sys/types.h>, so using it is safer than using
> uint32_t.
>
> > They *could* be changed to return unsigned, but I think this is worse
> > than u_int32_t.
>
> It is no different for an arch where unsigned is u_int32_t (both conflict
> with the man page :-).
Except that (IMHO) it shouldn't be documented as a non-numbered-type.
I would have thought that you'd be the first to agree with this -
you're the only person I know of that has exotic type sizes :-)
> Bruce
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 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.
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....
As for the src/usr.sbin/amd build - the only place that includes
machine/endian.h directly - I'm not sure what should be done about that.
At the moment it includes sys/types.h first (which includes
sys/endian.h !)...
--
Brian <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
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?200010181846.e9IIkZY00872>