Bruno Haible <[EMAIL PROTECTED]> 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.
