Date: Wed, 17 Sep 2008 19:33:48 +0300 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: arch@freebsd.org, Brooks Davis <brooks@freebsd.org>, John Hein <jhein@timing.com> Subject: Re: 64 bit time_t Message-ID: <87iqsuk9zn.fsf@kobe.laptop> In-Reply-To: <75968.1221600374@critter.freebsd.dk> (Poul-Henning Kamp's message of "Tue, 16 Sep 2008 21:26:14 %2B0000") References: <75968.1221600374@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 16 Sep 2008 21:26:14 +0000, "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote: >In message <20080916211646.GA35778@lor.one-eyed-alien.net>, Brooks Davis writes >>On Tue, Sep 16, 2008 at 02:17:16PM -0600, John Hein wrote: >>> Other than recompiling for -current users (and not being an MFC-able >>> change and possibly breaking a gazillion unfortunately written ports), >>> are their any other issues with switching to 64 bit time_t for i386? >>> I suppose compat libs are a bit dicey. >> >> Off hand: every syscall that takes a time_t or a structure containing >> a time_t would have to be reimplemented and a compatability >> version[...] > > This is a pretty nasty piece of work because it also involves the > timespec and timeval structures which appear in ioctls, socket > options, socket messages and so on. Wire-formats for network protocols are also going to be lots of fun too. icmp4's and tcp4's timestamp options (and other wire-protocol formats) use uint32_t. Presumambly, by the time 32-bits are no longer enough these wire-protools will be replaced by their more modern versions.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87iqsuk9zn.fsf>