BJ> We will need to address this long term.....  Using the Unix time
 BJ> standard would allow finear granularity,

 WM> Only by half. Surely, if a two-second limit is a problem, a one-second
 WM> limit will still be a problem?

More than by half.  I thought it was time_t, but I'd have to look again. 
There is a clock structure that has a signifcantly smaller time unit.

 BJ> but will break when the 32 bit clock rolls over -- depending on how 
 BJ> the rolling over of the epoch is handled in various flavors of Unix, 
 BJ> Linux, etc.

 WM> Since you specified 32-bit, that's 2038. (time_t doesn't have to be 32
 WM> bits; on some systems it's 64, which lasts for billions 
 WM> if not trillions of
 WM> years.) DJGPP instead uses an unsigned 32-bit value, which takes you a bit
 WM> past 2100 (the MS-DOS limit).

Any 64 bit implementation isn't directly compatiable with older systems I'm
familiar with.  If I remember right, the old tar data structures (used for
transfering files via tape between systems) did have an expansion word
properly located to add bits to the years, possibly go from 32 to 64 bits
for the int, but it's been a while since I've actually looked at stuff like
that.  And (from memory) the 2038 date is with the 32 bits as unsigned.....
 Yes, switching the ints from 32 bit to 64 bit is likely how the problem
will be resolved

I haven't looked at what DJGPP uses, but the 32 bit issue is one that's
been coded in C (and it's derivatives), and would be in any of the ANSI (or
K&R) C compatible setups....  

Take care.....

Bob Jones, 1:343/41

--- Maximus/2 3.01