Re: gettime's gettimeofday call may fail

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
...
>> Anyone who sets the system clock past 2038 and then runs a
>> gnulib-based program that they've compiled in
>> hamstrung-to-32-bit-time_t mode deserves whatever misbehavior they
>> provoke.
>
> I suppose a clock-hardware problem could provoke this, so it might not
> be the invoker's "fault".  (At least, not until we modify "configure"
> to generate 64-bit executables by default.  But that's a bigger
> subject....)
>
> How about the following idea?  If gettimeofday, clock_gettime,
> etc. fail with EOVERFLOW, invoke xtime_overflow, which prints a
> warning to stderr and returns the maximum time value.  Programs can
> override xtime_overflow in the same way that they can currently
> override xalloc_die.

I like it.  But why trigger only on EOVERFLOW?  at least for the current
next-to-last-resort gettimeofday call, it might be better to let any
nonzero return provoke failure, in case some other system sets errno to
a different value in this unusual case.

> gethrxtime and gettime should both share xtime_overflow; no sense
> reinventing the wheel.  Similarly for get_current_time in
> coreutils/src/ls.c.