From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 7 16:28:47 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8B0C16A41F for ; Fri, 7 Oct 2005 16:28:47 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 572E543D45 for ; Fri, 7 Oct 2005 16:28:47 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j97GSl8m014583; Fri, 7 Oct 2005 09:28:47 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j97GSkPi014582; Fri, 7 Oct 2005 09:28:46 -0700 Date: Fri, 7 Oct 2005 09:28:46 -0700 From: Brooks Davis To: Andreas Kohn Message-ID: <20051007162846.GB12691@odin.ac.hmc.edu> References: <1128644542.1273.36.camel@klamath.syndrom23.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eAbsdosE1cNLO4uF" Content-Disposition: inline In-Reply-To: <1128644542.1273.36.camel@klamath.syndrom23.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-hackers@freebsd.org Subject: Re: struct timeval: why is tv_sec long? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2005 16:28:47 -0000 --eAbsdosE1cNLO4uF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 07, 2005 at 02:22:22AM +0200, Andreas Kohn wrote: > Hi, >=20 > is there any special reason for timeval.tv_sec being long? tv_sec is presumably long becuase that way 64-bit platforms end up with timevals that don't suffer from the 2038 bug. time_t is also long (or rather synonimous with it) on all but alpha platforms. > --- sys/_timeval.h > /* > * Structure returned by gettimeofday(2) system call, and used in other > calls. > */ > struct timeval { > long tv_sec; /* seconds (XXX should be > time_t) */ > suseconds_t tv_usec; /* and microseconds */ > }; > --- >=20 > I just stumbled across this code in an application, > --- > timeval tv; > gettimeofday(&tv, 0); >=20 > char tbuf[64]; > struct tm tmp; > strftime(tbuf, sizeof(tbuf), "%b %d %H:%M:%S", localtime_r(&tv.tv_sec, > &tmp)); > --- >=20 > and this fails to compile on FreeBSD. I fixed the application code now, > but I do wonder why that XXX in sys/_timeval.h is there. > _timeval.h came into existence on 31-Dec-2002, before that timeval was > defined in sys/time.h with both tv_sec and tv_usec as long. >=20 > Could anyone offer any pointers? You probably can just cast the tv.tv_sec to a time_t. Alternativly, you could allocate a time_t and assing tv_sec to it since that will work on alpha where the other won't. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --eAbsdosE1cNLO4uF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDRqI+XY6L6fI4GtQRAqcVAKCjfDPoGncaMM7SzHu3RnvR8veoggCfV0aS YYWjw4cY5oz368twFhTMKr8= =fgr2 -----END PGP SIGNATURE----- --eAbsdosE1cNLO4uF--