On Sat, 25 Mar 2017, Hal Murray wrote:
> [email protected] said:
> > Oh, please, not more timespec crap.  The timeval and timespec stuff was just
> > a workaround for the lack of 64-bit integer support in C.  Once you can
> > count on 64-bit integers, then integer nanoseconds is a much cleaner format.
> >  A signed 64-bit nanosecond count has a range of +/- 292 years.
>
> Neat.  Thanks.
>
> Any hints that POSIX is interested?  Are there any library/packages or macros
> that we can steal/use?  (Much of the code I've been cleaning up is dealing
> with system interfaces.)

I don't know, though even if POSIX picked this up, it would probably be
past 2038 before one could generally count on it. :-)

Nevertheless, it's a perfectly reasonable *internal* representation, with
enough range and enough resolution to replace both time_t and timespec.

Also, don't count on timespec suddenly switching to a 64-bit time_t.  For
compatibility reasons, I expect that at least some platforms will have
both a "struct timespec" and a "struct timespec64" for some transitional
period.  Avoiding timespec for internal use lets issues of that form be
confined to the OS interface, rather than spread through the code.

Fred Wright
_______________________________________________
devel mailing list
[email protected]
http://lists.ntpsec.org/mailman/listinfo/devel

Reply via email to