From owner-svn-src-head@FreeBSD.ORG Fri Jun 12 02:56:57 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F8E8106566B; Fri, 12 Jun 2009 02:56:57 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 2A8F08FC14; Fri, 12 Jun 2009 02:56:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c122-106-159-184.carlnfd1.nsw.optusnet.com.au (c122-106-159-184.carlnfd1.nsw.optusnet.com.au [122.106.159.184]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n5C2uraw002956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 12:56:54 +1000 Date: Fri, 12 Jun 2009 12:56:53 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: John Baldwin In-Reply-To: <200906111437.n5BEbJdC050303@svn.freebsd.org> Message-ID: <20090612123608.F22046@delplex.bde.org> References: <200906111437.n5BEbJdC050303@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r194003 - head/sys/netinet X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 02:56:58 -0000 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