"Olson, Arthur David (NIH/NCI)" <olsona@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.wana... 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. :-)