Date: Mon, 19 Apr 2004 17:50:42 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Peter Wemm <peter@wemm.org> Cc: sparc64@freebsd.org Subject: Re: Minor problem with 64bTT: monthly accounting figures Message-ID: <p06020407bca9f9cd4c82@[128.113.24.47]> In-Reply-To: <200404191408.56929.peter@wemm.org> References: <20040301145508.GA27240@seekingfire.com> <20040301150312.GQ35475@elvis.mu.org> <p060204a1bc6936fd1174@[128.113.24.47]> <200404191408.56929.peter@wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 2:08 PM -0700 4/19/04, Peter Wemm wrote: > >Just fyi, ac does things like this: > > time_t ut_timecopy; > ut_timecopy = _time32_to_time(event_up->ut_time); > strlcpy(str_result, ctime(&ut_timecopy), sizeof(str_result)); > >However, there is also a big scary comment that says: > * With sparc64 using 64-bit time_t's, there is some system > * routine which sets ut_time==0 (the high-order word of a > * 64-bit time) instead of a 32-bit time value. > >It sounds like something clobbers ut_time.. Big scary comment added by me, when fixing 'ac' to do more reasonable things with such records... Afaik, we have still not figured out what it is that writes records with zero for the timestamp. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06020407bca9f9cd4c82>