From owner-freebsd-arch Sun Oct 28 5:11:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 1FE1637B401 for ; Sun, 28 Oct 2001 05:11:13 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id f9SDB7d60963; Sun, 28 Oct 2001 14:11:07 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id f9SD6bSe043726; Sun, 28 Oct 2001 14:06:38 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id f9SD6JF11644; Sun, 28 Oct 2001 14:06:19 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.4/8.11.4) id f9SD6Ju49881; Sun, 28 Oct 2001 14:06:19 +0100 (CET) (envelope-from ticso) Date: Sun, 28 Oct 2001 14:06:18 +0100 From: Bernd Walter To: Poul-Henning Kamp Cc: Matthew Dillon , arch@FreeBSD.ORG Subject: Re: illegal &time_t useage in /usr/src Message-ID: <20011028140618.A49388@cicely8.cicely.de> References: <20011028113509.A48670@cicely8.cicely.de> <33642.1004269374@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33642.1004269374@critter.freebsd.dk> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Oct 28, 2001 at 12:42:54PM +0100, Poul-Henning Kamp wrote: > In message <20011028113509.A48670@cicely8.cicely.de>, Bernd Walter writes: > >On Sat, Oct 27, 2001 at 11:38:56PM -0700, Matthew Dillon wrote: > > >But so far the discussion went completely to time_t only. > >What about struct timespec and struct timeval? > > We can't get rid of those, they API used. But still part of the original question. > >There is no functional need to have long defined tv_nsec and tv_usec > >fields as long as no spec says so. > > Right, I don't think anybody actually insisted on that. If time_t changes it's size struct timespec changes too. Why not correcting struct timespec.tv_nsec to int32_t in one turn? > >The tv_sec field on struct timeval would still be 32 bit on 32 bit > >platforms. > > You lost me there, I don't think that is mandated. Not mandated. It's simply part of the getting over 2038 thing. That said - I don't know which fields are forced to be long by standarts. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message