Alexander Bluhm <alexander.bluhm@gmx.net> wrote:

> The source of the u_long types are in the socket buffer.
> 
> struct sockbuf {
>         u_long  sb_cc;                  /* [m] actual chars in buffer */
>         u_long  sb_datacc;              /* [m] data only chars in buffer */
>         u_long  sb_hiwat;               /* [m] max actual char count */
>         u_long  sb_wat;                 /* [m] default watermark */
>         u_long  sb_mbcnt;               /* [m] chars of mbufs used */
>         u_long  sb_mbmax;               /* [m] max chars of mbufs to use */
> }
> 
> The were converted from u_short to u_long here:
> 
> commit 4924467d92d8f1e83e3d218800f0804c18ec2f95
> Author: Mike Karels <karels>
> Date:   Wed Jun 17 22:08:30 1987 -0700
> 
>     use longs for sockbuf counters, it fits!
> 
>     SCCS-vsn: 7.2

They were converted to long, when long was the same size as int.
It depended on rounding and saturation during of the type, during
a time when there was no larger type.  (When long long arrived later,
of quad_t really, it was primarily used in the VFS layer.)

> Are you really suggesting to convert them to u_int?  This would
> need a review of all comparisons in all domains and protocols.  I
> doubt that this is feasible.

I think the mistake made is that this wasn't reviewed when machines
with 64-bit long instead of 32-bit long arrived.  The signed vs
unsigned wraps are at different points on half the architectures,
which I suspect requires _MORE REVIEW AND CARE_ than if the math
was constricted to the consistant type u_int.

u_long is fragile.  How have other systems handled this?  By slowly
deciding that 32-bit machines don't exist?