Date: Fri, 26 Oct 2001 00:49:45 -0400 From: Mike Barcroft <mike@FreeBSD.ORG> To: Peter Wemm <peter@wemm.org> Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011026004945.I93553@coffee.q9media.com> In-Reply-To: <20011025233602.587C63808@overcee.netplex.com.au>; from peter@wemm.org on Thu, Oct 25, 2001 at 04:36:02PM -0700 References: <20011025233602.587C63808@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm <peter@wemm.org> writes: > 4) Pro: > All wire and on-disk formats mentioning time_t will be compatable > across the entire freebsd range. > The Pentium21 (to be released in year 2021) will be Y2038 safe. :-) > Con: > Break i386 *.o compatability. We would be subjecting ourselves to > the same sort of pain that the rest of the unix world went through > (and is still going through with the 64 bit filesize transition). > Doesn't solve things like "int32_t start_time;" in exposed disk and > on-the-wire structures. > Printf format hell (%qd on i386, %ld on the 64 bit platforms) where > it causes real screwups if there is a mistake. I vote for 4. The issue with printf(9) could be solved by using the new C99 type intmax_t (which defines the largest possible integer type available) and printf() counterpart %j. Ofcourse this might be a problem if we port to a 128 bit processor. Best regards, Mike Barcroft 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?20011026004945.I93553>