Florian Weimer wrote:
> time can definitely return the
> value of a variable that is incremented periodically from the timer
> interrupt.

Is that variable the one that CLOCK_REALTIME_COARSE uses? If so, and if we're 
going to replace calls to 'time' with calls to 'clock_realtime', we can do 
either of the following:

* Use CLOCK_REALTIME_COARSE. This takes less CPU time and its behavior better 
matches what the current glibc does.

* Use CLOCK_REALTIME. This will lessen bugs due to naive code (quite possibly 
some code within glibc!) which assumes that 'time (0)' and clock_gettime 
(CLOCK_REALTIME, ...)' use the same clock.

It sounds you're leaning towards (1) and I'm inclined to agree. However, 
shouldn't the manual say that 'time' does not necessarily agree with 
CLOCK_REALTIME? The current behavior is a trap for the unwary.


To illustrate the problems with naive code, see the attached program. On my 
Fedora 30 x86-64 desktop, './a.out' outputs this:

clock_gettime (CLOCK_REALTIME, ...) yielded a seconds count of 1567026298;
then time (0) yielded a seconds count of 1567026297, which was 1 s earlier.
Time warp!

In contrast, './a.out 1' (which uses CLOCK_REALTIME_COARSE) finds no 
discrepancies in 2**32 attempts.