Asctime.c

[Paul Eggert]

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

> 1. The POSIX standard calls for a struct tm that includes an "int tm_year"
> member. If time_t is 64 bits and int is 32 bits, tm_year won't be able to
> represent all the years associated with time_t values. Should the standard
> address this issue?

This isn't an issue of asctime per se, since asctime doesn't deal with
time_t values.  From an asctime point of view, the only problem is
that the behavior can be undefined is when tm_year etc. are out of
range.  A "nice" implementation like tz asctime uses a wider buffer
than 26 bytes internally, and (on a 64-bit host, at least) will always
print the mathematical value of tm_year+1900 rather than overflowing
the integer.  A "not so nice" implementation will dump core or worse.

This is, however, an issue for other primitives like localtime.  Here,
POSIX says that these primitives return a failure value when time_t is
out of range.  E.g., localtime returns NULL and sets errno to EOVERFLOW.

> 2. The standard reads...
> 	The asctime_r() function shall convert the broken-down time in the
> 	structure pointed to by tm into a string (of the same form as that
> 	returned by asctime()) that is placed in the user-supplied buffer
> 	pointed to by buf (which shall contain at least 26 bytes) and then
> 	return buf.
> ...but a 26-byte buffer won't be adequate if a five-digit (or more) year is
> involved.
> Should the standard address this issue? Should "asctime_r" assume that the
> fed-in buffer is at most 26 bytes and avoid overflowing it?

The standard says the behavior of asctime_r is undefined in this case.
Practically speaking, it's the user's responsibility to pass in a
buffer that is long enough, as I think most implementations will
overflow it.  I've heard that HP-UX asctime_r returns NULL and sets
errno==EOVERFLOW in this case, but it is too restrictive the other
way: it rejects dates before 1900, and this behavior clearly does not
conform to the C Standard.

This issue has come up on the POSIX mailing lists; e.g. see
<http://www.opengroup.org/sophocles/show_mail.tpl?source=L&listname=austin-group-l&id=6606>.


> 	** The format used in the (2004) standard is
> 	**	"%.3s %.3s%3d %.2d:%.2d:%.2d %d\n"
> 	** Use "%02d", as it is a bit more portable than "%.2d".
> 	** Drop each .3 since they're superfluous given how we set wn and
> mn.
> 	*/
> 	(void) sprintf(buf, "%s %s%3d %02d:%02d:%02d %ld\n",
> 		wn, mn,

It's not correct to drop the two .3's here, since wn and mn might not
be null terminated: they usually point to arrays of 3 characters that
are not null-terminated.