Re: gettime's gettimeofday call may fail

[Paul Eggert]

Jim Meyering <address@hidden> writes:

> At first I thought this meant we'd have to change gettime to
> return an indication of success or failure.  However, I am now
> inclined to leave it as is.

Yes, that sounds right to me, too.

> 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.

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