svn commit: r194003 - head/sys/netinet

[Bruce Evans]

On Thu, 11 Jun 2009, John Baldwin wrote:

> Log:
>  Correct printf format type mismatches.
>
> Modified:
>  head/sys/netinet/tcp_usrreq.c

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
> 	    tp->snd_recover);
>
> 	db_print_indent(indent);
> -	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
wrong format.

Bruce