From owner-freebsd-hackers Thu Jun 22 15:27:37 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA01555 for hackers-outgoing; Thu, 22 Jun 1995 15:27:37 -0700 Received: from gateway.cybernet.com (gateway.cybernet.com [192.245.33.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA01543 for ; Thu, 22 Jun 1995 15:27:33 -0700 Received: by gateway.cybernet.com (8.6.8/1.0A) id TAA05634; Thu, 22 Jun 1995 19:03:28 -0400 Date: Thu, 22 Jun 1995 19:03:28 -0400 From: mtaylor@gateway.cybernet.com (Mark J. Taylor) Message-Id: <199506222303.TAA05634@gateway.cybernet.com> To: hackers@freebsd.org Subject: brokenness in kern_time.c: timevalfix() Sender: hackers-owner@freebsd.org Precedence: bulk I've noticed that timevalfix() does not calculate fixes 'correctly' (completely). I assume that it is suposed to take a given timeval structure and 'fix' it so that tv_usec is less than one million and greater than zero, while adjusting tv_sec appropriately. void timevalfix(t1) struct timeval *t1; { if (t1->tv_usec < 0) { /* <------------- should be 'while'? t1->tv_sec--; t1->tv_usec += 1000000; } if (t1->tv_usec >= 1000000) { /* <------------- should be 'while'? t1->tv_sec++; t1->tv_usec -= 1000000; } } Another way to fix it would be to do an integer division of tv_usec by 1000000 to determine how many seconds need to be added / subtracted: int sec_cor; sec_cor = t1->tv_usec / 1000000; t1->tv_sec += sec_cor; t1->tv_usec -= sec_cor * 1000000; Also, timevalfix() is called by timevaladd() and timevalsub(), so why is it being called in settimeofday() right after a timevaladd()? Isn't this redundant? These 'problems' have been in kern_time.c at least since FreeBSD 1.1.5.1. Would someone please explain to me why not to fix timevalfix()? Does it have to do with speed, or (possibly) other routines rely on this 'brokenness'? -Mark Taylor mtaylor@cybernet.com