eggert at CS.UCLA.EDU
Tue Oct 12 17:46:05 UTC 2004
"Olson, Arthur David (NIH/NCI)" <olsona at dc37a.nci.nih.gov> writes:
> The notion would be to rely on strftime only to handle the year (along the
> lines below); this would avoid some of the problems folks have noted.
The main remaining problem is that asctime.c is no longer decoupled
from the rest of the tz code, as that change would cause it to assume
that it is invoking tz's strftime, not some other (conforming)
strftime. This is because conforming strftime implementations are
allowed to dump core if you give them (say) tm_mday out of range, even
if they don't need to access tm_mday to do their job.
If we make it clear that asctime.c cannot invoke just any conforming
strftime, but must invoke one that acts like our strftime, then we
should be OK. That could be done in a comment, I think. Something like
** Use strftime to convert %Y, to avoid overflow problems when
** computing timeptr->tm_year + TM_YEAR_BASE. Assume that strftime
** behaves like the tz strftime, in that it is unaffected by other
** out-of-range members (e.g., timeptr->tm_mday) when processing "%Y".
(void) strftime(year, sizeof year, "%Y", timeptr);
More information about the tz