From owner-freebsd-arch Sun Oct 28 2:35: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 2BF2C37B401 for ; Sun, 28 Oct 2001 02:35:15 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id f9SAZAu59311; Sun, 28 Oct 2001 11:35:11 +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 f9SAZPSe042430; Sun, 28 Oct 2001 11:35:26 +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 f9SAZ8F11475; Sun, 28 Oct 2001 11:35:08 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.4/8.11.4) id f9SAZBS49135; Sun, 28 Oct 2001 11:35:11 +0100 (CET) (envelope-from ticso) Date: Sun, 28 Oct 2001 11:35:09 +0100 From: Bernd Walter To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: illegal &time_t useage in /usr/src Message-ID: <20011028113509.A48670@cicely8.cicely.de> References: <200110280638.f9S6cuA99947@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110280638.f9S6cuA99947@apollo.backplane.com> 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 Sat, Oct 27, 2001 at 11:38:56PM -0700, Matthew Dillon wrote: > I found 14 instances of illegal time_t casts. They all look very > easy to fix. Most are protocol-related so the correct solution is > truncation. About half assume sizeof(time_t) == sizeof(int). The > other half assume sizeof(time_t) == sizeof(long). I think a couple > even assume sizeof(time_t) == sizeof(int32_t). > > I found about a hundred instances of non-fatal time_t truncation > (i.e. program works fine with 64 bit time_t's but will blow up after > 2038 (would blow up anyway if not fixed by 2038 no matter what the > platform)). named alone is very amusing code... it squeaks in and > appears to produce runnable (truncation mode) code, but boy is it > a hodge podge of useages. > > All told I found numerous instances where time_t was assumed to be > exactly equivalent to ... int, long, > ulong, int32_t, void *, etc... but only 14 where pass-by-reference > cast overrides produced broken code. All the problem areas are minor > and can be fixed in a few minutes. Most of the protocols could even > be upgraded (instead of truncating), though I see no particular reason > to create the incompatibility just now. The elf and a.out timestamps > would have to be left in truncated mode for obvious reasons. Some of > the newer cpio protocols are already good for 11 digits and I've > comitted those changes, as well as some other minor fixups. > > The next step is for me to do the syscall roll, test with 32 bit > binaries, then do a full 64 bit buildworld and test a full 64 bit time_t > system. Patches will probably be available for wider testing next week > sometime. I'll also get in touch with the contrib owners in regards to > their time_t issues. > > Most of these bugs are bugs that have to be fixed for 64 bit platforms > and/or for 64 bit platforms / 64 bit time_t anyway. I won't actually > commit any IA32/64-bit time_t changes for at least another month, > assuming I can push that part of it through. That's good to hear. But so far the discussion went completely to time_t only. What about struct timespec and struct timeval? There is no functional need to have long defined tv_nsec and tv_usec fields as long as no spec says so. The tv_sec field on struct timeval would still be 32 bit on 32 bit platforms. What about sub nsec representations? -- 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