From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 9 15:35:15 2012 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B81404E8 for ; Tue, 9 Oct 2012 15:35:15 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) by mx1.freebsd.org (Postfix) with ESMTP id 757198FC08 for ; Tue, 9 Oct 2012 15:35:14 +0000 (UTC) Received: from [192.168.1.18] (unknown [217.157.7.221]) by csmtp2.one.com (Postfix) with ESMTPA id B44F93018818 for ; Tue, 9 Oct 2012 15:35:07 +0000 (UTC) From: Erik Cederstrand Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: time_t when used as timedelta Message-Id: <787F09EF-E3F7-467E-B023-B7846509D2A1@cederstrand.dk> Date: Tue, 9 Oct 2012 17:35:09 +0200 To: FreeBSD Hackers Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:35:15 -0000 Hi list, I'm looking at this possible divide-by zero in dhclient: = http://scan.freebsd.your.org/freebsd-head/WORLD/2012-10-07-amd64/report-nB= hqE2.html.gz#EndPath In this specific case, it's obvious from the intention of the code that = ip->client->interval is always >0, but it's not obvious to me in the = code. I could add an assert before the possible divide-by-zero: assert(ip->client->interval > 0); But looking at the code, I'm not sure it's very elegant. = ip->client->interval is defined as time_t (see = src/sbin/dhclient/dhcpd.h), which is a signed integer type, if I'm = correct. However, some time_t members of struct client_state and struct = client_config (see said header file) are assumed in the code to be = positive and possibly non-null. Instead of plastering the code with = asserts, is there something like an utime_t type? Or are there better = ways to enforce the invariant? Thanks, Erik=