asctime.c

[Paul Eggert]

"Olson, Arthur David (NIH/NCI)" <olsona at dc37a.nci.nih.gov> writes:

> That last "%d" in the sprintf would indeed produce less than four digits of
> year output in some cases.

Yes, that's right.

> Of course we might also take the above as meaning that it's mandatory for
> asctime to overflow a buffer (and potentially dump core) for other cases
> (take tm_year >= 10000, please).

This issue has come up on the comp.std.c newsgroup, most recently
in the enormous "Buffer overflow in the C standard?" thread that
started May 28.  Here's a URL if you want to read the gory details:

http://groups.google.com/groups?threadm=c972ch%24h97%241%40news-reader4.wanadoo.fr

The consensus opinion is that, if the asctime code that you quoted has
defined behavior, then a conforming C implementation must exhibit that
behavior; if not, the implementation is free to do whatever it wants
to, because the behavior is undefined.  At least, this is the opinion
endorsed by the members of the standardization committee in
comp.std.c, and I vaguely recall that they affirmed it in response to
a defect report.

Therefore, when tm_year >= 10000, the asctime implementation is
allowed to dump core or generate a wrong answer (because of the buffer
overflow in the standard code), but it is not required to do so: it
can return a correct string (by using a larger static buffer than
required; the standard allows this).  Similarly, when tm_year ==
INT_MAX, the implementation is allowed to dump core or generate a
wrong answer (since adding 1900 overflows the int value in the
standard code); but the implementation can return a correct string
instead (by using a wider integer to do arithmetic).

> Sidebar: I believe kre is proposing padding with spaces rather than zeroes.

Well, the Unix V7 code generated only years in the range 1900-2099,
regardless of what tm_year was.  (I doubt whether that's what he
wants.  :-)