Date: Wed, 17 Sep 2008 09:34:10 -0600 From: John Hein <jhein@timing.com> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: arch@freebsd.org, Brooks Davis <brooks@freebsd.org> Subject: Re: 64 bit time_t Message-ID: <18641.9074.499346.988999@gromit.timing.com> In-Reply-To: <75968.1221600374@critter.freebsd.dk> References: <20080916211646.GA35778@lor.one-eyed-alien.net> <75968.1221600374@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote at 21:26 +0000 on Sep 16, 2008: > In message <20080916211646.GA35778@lor.one-eyed-alien.net>, Brooks Davis writes > : > > > >--PEIAKu/WMn1b1Hv9 > >Content-Type: text/plain; charset=us-ascii > >Content-Disposition: inline > > > >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. Okay. Sounds "fun". So for systems where we don't care about compatibility (where a product is built from scratch and we don't have to worry about 3rd party binary libs/programs), the problems mentioned by brooks & phk disappear. No one wants to play the performance or atomic access card?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18641.9074.499346.988999>