Date: Sun, 28 Oct 2001 11:35:09 +0100 From: Bernd Walter <ticso@cicely8.cicely.de> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: arch@FreeBSD.ORG Subject: Re: illegal &time_t useage in /usr/src Message-ID: <20011028113509.A48670@cicely8.cicely.de> In-Reply-To: <200110280638.f9S6cuA99947@apollo.backplane.com> References: <200110280638.f9S6cuA99947@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <pick just about any int type here>... 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011028113509.A48670>