> 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 

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 <[EMAIL PROTECTED]>                        <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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to