From: "Theo de Raadt" Subject: Re: TCP window shifts unsinged long To: Alexander Bluhm Cc: Mark Kettenis , tech@openbsd.org Date: Mon, 11 Aug 2025 08:58:14 -0600 Alexander Bluhm 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 > 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?