Date: Mon, 22 Dec 2003 08:51:23 -0600 From: Craig Boston <craig@xfoil.gank.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: current@freebsd.org Subject: Re: An experiment: 64-bit time_t on IA-32 (5.2-RC) Message-ID: <200312220851.24133.craig@xfoil.gank.org> In-Reply-To: <20031222080115.GA645@server.vk2pj.dyndns.org> References: <200312212239.38557.craig@xfoil.gank.org> <20031222080115.GA645@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 22 December 2003 02:01 am, Peter Jeremy wrote: > This has been discussed on either -arch or -hackers sometime in the > past year or so. Thanks -- my search-fu hasn't been good enough to summon those discussions yet but I'll keep looking. All I've found so far is some discussion of the filesystem timestamps, which seems to be moot now with UFS2. I suspect the biggest problem is figuring out a way to not break the ABI (some of my search hits vaguely mentioned new syscalls/libc functions, but those were referencing other posts I couldn't find). Also, I *thought* someone had done this before (on i386) and posted to -current or maybe -hackers about it, but now I can't seem to find it :( > Only UFS2. UFS1 has a 32-bit timestamp and an adjacent spare 32-bit field. That's funny. My filesystems are using UFS1 so that grub can read them :-/ > That's a good start. Have you tried cross-checking those calculations > via an independent codebase? (I have no idea whether they're right or > wrong but it's worth a double check). Not yet -- I don't have a real 64-bit platform to see what one says. I guess I could try doing the math by hand and see how it turns out. Would be nice if I could get the amd64 kernel booted in bochs ;) > The next test would be setting the date to (say) 2038-Jan-19 03:14 UTC, > waiting 10 seconds and seeing what various utilities do. Will do. This is my main PC at home so it should get a pretty thorough workout. Right now I'm recompiling world again because I didn't notice that struct timeval had long hard-coded for tv_sec :( I'm also building a list of ports that fail due to assumptions about sizeof(time_t) == sizeof(long). Ones that I'm able to fix I'll send patches to the developers for. So far the ones that have failed are: * ezm3 won't "compile". It seems to be already precompiled into assembly though, so I suspect it needs to be re-bootstrapped. I have no idea how to go about it, though. * ruby16 compiles but portupgrade tends to freeze and eat up 100% CPU. I tracked it down to a function being defined with time_t arguments but being called with longs. It didn't get automatically casted since the function in question used a K&R style declaration without a prototype, so it ended up with bogus data. Simple fix. * kdelibs3 won't compile. Opposite issue -- trying to pass time_t to a function declared for longs. Since it's C++ it just caused a compile error rather than strange results. I managed to work around it by statically casting to long, but it's not a correct fix and will break in 2038. --Craig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200312220851.24133.craig>