From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 23 08:04:56 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E634A16A4CE; Tue, 23 Dec 2003 08:04:55 -0800 (PST) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41D6A43D1D; Tue, 23 Dec 2003 08:04:54 -0800 (PST) (envelope-from craig@tobuj.gank.org) Received: from localhost (ion.gank.org [69.55.238.164]) by ion.gank.org (mail) with ESMTP id C98872B506; Tue, 23 Dec 2003 10:04:52 -0600 (CST) Received: from ion.gank.org ([69.55.238.164]) by localhost (ion.gank.org [69.55.238.164]) (amavisd-new, port 10024) with LMTP id 51012-01; Tue, 23 Dec 2003 10:04:51 -0600 (CST) Received: from owen1492.uf.corelab.com (pix.corelab.com [12.45.169.2]) by ion.gank.org (mail) with ESMTP id 4295E2B504; Tue, 23 Dec 2003 10:04:51 -0600 (CST) From: Craig Boston To: Peter Jeremy Date: Tue, 23 Dec 2003 10:04:40 -0600 User-Agent: KMail/1.5.4 References: <200312212239.38557.craig@xfoil.gank.org> <200312220851.24133.craig@xfoil.gank.org> <20031223065236.GA29936@cirb503493.alcatel.com.au> In-Reply-To: <20031223065236.GA29936@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312231004.40480.craig@tobuj.gank.org> X-Virus-Scanned: by amavisd-new at gank.org cc: freebsd-hackers@freebsd.org Subject: Re: An experiment: 64-bit time_t on IA-32 (5.2-RC) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2003 16:04:56 -0000 This is probably more appropriate on -hackers at this point, so I'm redirecting there. Bcc current so interested parties know where to look. I'm also changing my From: to my -hackers address, so don't be alarmed ;) On Tuesday 23 December 2003 12:52 am, Peter Jeremy wrote: > I don't recall that. I notice time_t is 'long' on i386 so bde's > ia32-with-64-bit-longs will also have 64-bit time_t. That may be what I'm thinking of. > Looks like I was wrong about the adjacent field being spare - it seems > it _has_ been used for high-res timestamps since I looked last. The discussion I did find mentioned that that field had been used for milliseconds or something. Hopefully by 2038 there won't be too many UFS1 filesystems left ;) > I was thinking of a totally independent implementation - eg the > algorithms in Edward M. Reingold's "Calendrical Calculations". > Agreeing with FreeBSD on an iA64 or amd64 could just be common bugs. Ahhhh, math :) I'll try cooking something up and see how it turns out. I'll also run those numbers through my trusty HP-48 and see what it thinks as well. > >Right now I'm recompiling world again because I didn't notice that struct > >timeval had long hard-coded for tv_sec :( > > gcc should be able to pick this up for you. I'm not sure I understand... Right now I'm really wishing I had gone ahead and implemented some compat functions in libc and the kernel so that old binaries would work. Being without cvsup is no fun at all. I tried to update ports using anoncvs, but that was slooooow and eventually died. > This isn't true now on Alpha and SPARC so I thought they had all been > ironed out. You may still get bitten if sizeof(time_t) > sizeof(long). I think that's exactly what's happening. All the cases I've isolated so far involve trying to stuff a time_t into a long (or sometimes even an int!), so if sizeof(long) > sizeof(time_t) it wouldn't be a problem. The kdelibs one is no fun. There are a couple places in KDE where a time_t is stored in some sort of configuration object -- the interface is slightly reminiscent of the Windows registry. The storage function is overloaded, so if I make sure there is one for long long it will be able to store it just fine no matter what the architecture. Getting it out is trickier since you have to know ahead of time what the type is in order to call the correct retrieval function (readLongNum, readLongLongNum, etc.) Currently I'm thinking about doing something like #if sizeof(time_t) == sizeof(long) #define readTimeTNum readLongNum #elif sizeof(time_t) == sizeof(long long) #define readTimeTNum readLongLongNum ... but that's really ugly. Surely there's a better way? Craig