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