[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gnulib] removing asctime_r, ctime_r from the time_r module

From: Paul Eggert
Subject: Re: [bug-gnulib] removing asctime_r, ctime_r from the time_r module
Date: Mon, 24 Apr 2006 11:47:54 -0700
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

Bruno Haible <address@hidden> writes:

> Unlike gets() and the termcap functions, these functions don't need a buffer
> of arbitrary size. Only the initially specified size was too small. The
> functions would be OK to use in GNU programs if a buffer of size 100 was
> used rather than a buffer of size 26, no?

Yes and no.  In a practical sense, I doubt whether any implementation
today will overrun a buffer of size 100.  However, in practice many C
implementations get it wrong anyway, so we still shouldn't encourage
the use of these functions.  Either their ctime/ctime_r
implementations assume that localtime/localtime_r will always succeed
(so they dereference a NULL pointer), or they generate incorrect (but
fits-in-buffer) output for out-of-range time stamps.

For example, the safe time_t range in Solaris is only the years 1900
through 9999.  ctime_r and asctime_r return NULL with errno==EOVERFLOW
for years past 9999, but they silently generate the wrong string for
years before 1900.  For example, on my 64-bit Solaris 10 host using
UTC, for the time stamp -429496729 ctime_r and asctime_r generate the
string "Sun Nov 24 17:31:44 1933" even though the correct year is
1833.  For the time stamp -549755813888 they generate the string "Fri
Dec  5 11:41:52 19 ." (no buffer overflow, but quite wrong!) even
though the correct year is -15452.

It's OK to use ctime/asctime/etc. if you know that the time stamp is
in a safe range for the current C library, but determining the safe
range for an arbitrary C library is fairly tricky, and I don't think
it's worth the hassle.  (Recent-enough glibc is always safe, but most
GNU code wants to run elsewhere too.)

The next POSIX will allow the current Solaris behavior, along with
worse behaviors, so I think it's better if we wash our hands of these
functions entirely.  asctime and ctime are only historical curiosities
now, and asctime_r and ctime_r are well-intentioned mistakes.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]