[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gettime's gettimeofday call may fail
From: |
Paul Eggert |
Subject: |
Re: gettime's gettimeofday call may fail |
Date: |
Sun, 23 Oct 2005 02:30:21 -0700 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
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.