Paul Eggert <[EMAIL PROTECTED]> 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. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
