Date: Fri, 12 Jun 2009 12:56:53 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: John Baldwin <jhb@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r194003 - head/sys/netinet Message-ID: <20090612123608.F22046@delplex.bde.org> In-Reply-To: <200906111437.n5BEbJdC050303@svn.freebsd.org> References: <200906111437.n5BEbJdC050303@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090612123608.F22046>