Re: gethrxtime: fall back on gettime?

[Jim Meyering]

Paul Eggert <address@hidden> wrote:

> Jim Meyering <address@hidden> 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.