Minor problem with 64bTT: monthly accounting figures

Peter Wemm peter at wemm.org
Mon Apr 19 14:09:48 PDT 2004

On Monday 01 March 2004 11:03 am, Garance A Drosihn wrote:
> At 4:03 PM +0100 3/1/04, Maxime Henrion wrote:
> >Tillman Hodgson wrote:
> >>  Look a little odd this month:
> >>
> >>  Subject: caliban.rospa.ca monthly run output
> >>
> >>  Doing login accounting:
> >>          root                 0.84
> >>          total            -298848.27
> >>          toor             -298849.12
> >>
> >  > -- End of monthly output --
> This would be from the output of the 'ac' command.  I tried
> this on my 64-bTT machine, and it seemed to be working OK.
> >This is probably because the time is stored as a 32-bits integer
> >in /var/run/utmp and /var/log/wtmp.
> If the time-value is defined as a fixed 32-bit integer (instead
> of being time_t), then the records themselves should be fine.  The
> records (as written) won't be changing in size due to this change.        
> So, if there is a bug here then it'll probably be in the 'ac'
> program.  That's my guess, at least.  We can look into that some
> more, but don't need to address it right away.

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..
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5

More information about the freebsd-sparc64 mailing list