Since 9/8/2001, the decimal representation of unix time has gone to 10
digits. this breaks some of the format code within nmh...
scan -format "%(clock{date})" last:8
709866431
709903284
709904310
70990506=
70990544;
70990577=
709906789
70990686:
The following patch fixes the problem for me:
*** sbr/fmt_scan.c.~1~ Sun Sep 26 13:45:56 1999
--- sbr/fmt_scan.c Fri Sep 21 12:09:25 2001
***************
*** 282,289 ****
char *cp, *ep, *sp;
char *savestr, *str = NULL;
char buffer[BUFSIZ], buffer2[BUFSIZ];
! int i, c, ljust;
! int value = 0;
time_t t;
struct format *fmt;
struct comp *comp;
--- 282,289 ----
char *cp, *ep, *sp;
char *savestr, *str = NULL;
char buffer[BUFSIZ], buffer2[BUFSIZ];
! int i, ljust;
! int64_t c, value = 0;
time_t t;
struct format *fmt;
struct comp *comp;
The problem lies in the guts of the PUTD() macro, which
contain the following code fragment:
c = 10;
while (c <= i)
c *= 10;
The repeated "c *= 10" done here will overflow a 32-bit signed integer
when i is greater than 1 billion, resulting in mangled output.
The crude, but effective, hack above extends the range of "c" so that
it doesn't overflow in this case -- however, not all platforms may
support the int64_t type yet.
It might make more sense, however, to rework the macros to use
sprintf() or snprintf() instead.
- Bill
