eggert at CS.UCLA.EDU
Tue Jul 20 23:59:08 UTC 2004
"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
> 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
> ** 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
> (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.
More information about the tz