svn commit: r194003 - head/sys/netinet
brde at optusnet.com.au
Fri Jun 12 02:56:58 UTC 2009
On Thu, 11 Jun 2009, John Baldwin wrote:
> Correct printf format type mismatches.
This is backwards. As I explained in the mail that pointed out this bug,
the bug is that the variables should have remained having an unsigned type.
> Modified: head/sys/netinet/tcp_usrreq.c
> --- head/sys/netinet/tcp_usrreq.c Thu Jun 11 14:36:13 2009 (r194002)
> +++ head/sys/netinet/tcp_usrreq.c Thu Jun 11 14:37:18 2009 (r194003)
> @@ -1823,7 +1823,7 @@ db_print_tcpcb(struct tcpcb *tp, const c
> - db_printf("t_maxopd: %u t_rcvtime: %u t_startime: %u\n",
> + db_printf("t_maxopd: %u t_rcvtime: %d t_startime: %d\n",
> tp->t_maxopd, tp->t_rcvtime, tp->t_starttime);
The times are unsigned integers mod (UINT_MAX + 1) (except for these bugs).
E.g., the time INT_MAX is 1 less than the time ((u_int)INT_MAX + 1). With
the times obfuscated as being ints, (INT_MAX + 1) overflows and gives
undefined behaviour, normally to the value INT_MIN with no trap on 2's
complement machines. Then the difference (INT_MIN - INT_MAX) overflows and
gives undefined behaviour, normally to the value 1 which is what is wanted.
Printing the values in a bug-for-bug compatible format mainly exposes this
misbehaviour to users. In the overflowing case that you just fixed, the
user would see times near INT_MAX and INT_MIN and have to know that
INT_MAX = 2147483647 and INT_MIN = -2147483647 is really one larger than
INT_MAX to debug these times. (With the old broken u_long types, on 64-bit
machines the user migh see the much less familiar number (uint64_t)INT_MIN =
2^64 - 2^31 = 18446744071562067968.) With correct u_int types, the user
will see an apparent discontinuity at UINT_MAX = 4294967295 wrapping to 0,
but that is easier to understand because 0 is much shorter than 2147...
or 1844... The user might also be confused printing out `int ticks'
in %d format, but then in ddb it is the user's fault for using the
More information about the svn-src-all