Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> What do you think of making gethrxtime fall back on gettime? > > Yes, that makes sense to me. I installed the patch below. This > also fixes the comments to match the code.
Looks fine. Thanks! >> While we're on the subject, how about removing gettime's use >> of time? If there is a system lacking all of the preceding >> functions, then we should find/use a function it does provide >> that has some sub-second precision rather than using `time (NULL)', >> which has none. Then we could say that the function is guaranteed >> to provide at least nominal sub-second precision. > > Hmm, my kneejerk reaction is that there are no guarantees with clocks. The key word is `nominal' :-) When we resort to using `time (NULL)', we know that in some cases there is *no* chance of sub-second precision. > Even if we successfully invoke clock_gettime or gettimeofday, there's > still no guarantee that the clock has subsecond precision, as it could > be a gettimeofday emulator running atop a clock with 1-second > resolution. Sure, when it comes to standards and time-related functions there's never a mandated precision. But in practice, why worry? Isn't it better to avoid imposing such a limit ourselves? > Also, if we insist on not calling time(), that means we'd have to > delve into Microsoft's _ftime in order to port to mingw, right? I'd > rather avoid _ftime if I could. Assuming someone cares about the affected systems, I'd be happy to let them do it. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib