Subject: Re: fallout from use of u_int32_t in i386
To: None <jconklin@netcom.com>
From: Mike Long <mike.long@analog.com>
List: current-users
Date: 05/08/1996 13:44:47
>From: jconklin@netcom.com (J.T. Conklin)
>Date: Mon, 6 May 1996 18:05:42 -0700 (PDT)
>
[I wrote:]
>> I had to fix some files in order to get my system to build after
>> /sys/arch/i386/include/endian.h was changed to use u_int{16,32}_t
>> in the [hn]to[nh][sl]() macros.  It is now necessary to #include
>> <sys/types.h> before <machine/endian.h> on the i386.  Some of the
>> affected files (the ones I remember) were:

Here's an updated list of affected files:

src/lib/libc/stdlib/strtod.c
src/lib/libm/src/math_private.h
src/bin/ed/main.c	# uses <sys/wait.h>
src/bin/ed/glbl.c
src/usr.sbin/amd/config/os-bsd44.h

>Bleh.  
>
>Changing htonl() and friends to use fixed sized was clearly the right
>thing to do, but we should have checked for standards/prior art before
>it was done.  Since this is usually my domain, I take responsibility.
>
>XPG4.2 declares the types of these functions to be in_port_t and
>in_addr_t.  in_port_t is a "Unsigned integral type of exactly 16 bits"
>and in_addr_t is a "Unsigned integral type of exactly 32 bits.  Both
>types are to be defined in netinet/in.h and arpa/inet.h.

I looked into this, and noticed that htonl() et. al. are in neither of
those headers.  Are you implying that <netinet/in.h> and <arpa/inet.h>
should #include <machine/endian.h> to get those definitions (and the
htonl() macro family)?

>Since machine/endian.h is a machine dependent header, I think we can
>safely define the in_addr_t / in_port_t types without reference to 
>u_int{16,32}.

Yup.  Or just change back src/sys/arch/i386/include/endian.h :-).
-- 
Mike Long <mike.long@analog.com>     <URL:http://www.shore.net/~mikel>
VLSI Design Engineer         finger mikel@shore.net for PGP public key
Analog Devices, CPD Division          CCBF225E7D3F7ECB2C8F7ABB15D9BE7B
Norwood, MA 02062 USA       (eq (opinion 'ADI) (opinion 'mike)) -> nil