At the end of this message is a revised version of asctime.c. There are a couple of standard-related matters. 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? 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? --ado /* ** This file is in the public domain, so clarified as of ** 1996-06-05 by Arthur David Olson (arthur_david_olson@nih.gov). */ #ifndef lint #ifndef NOID static char elsieid[] = "@(#)asctime.c 7.11"; #endif /* !defined NOID */ #endif /* !defined lint */ /*LINTLIBRARY*/ #include "private.h" #include "tzfile.h" /* ** A la ISO/IEC 9945-1, ANSI/IEEE Std 1003.1, 2004 Edition. */ char * asctime_r(timeptr, buf) register const struct tm * timeptr; char * buf; { static const char wday_name[][3] = { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" }; static const char mon_name[][3] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" }; register const char * wn; register const char * mn; if (timeptr->tm_wday < 0 || timeptr->tm_wday >= DAYSPERWEEK) wn = "???"; else wn = wday_name[timeptr->tm_wday]; if (timeptr->tm_mon < 0 || timeptr->tm_mon >= MONSPERYEAR) mn = "???"; else mn = mon_name[timeptr->tm_mon]; /* ** 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, timeptr->tm_mday, timeptr->tm_hour, timeptr->tm_min, timeptr->tm_sec, timeptr->tm_year + (long) TM_YEAR_BASE); return buf; } /* ** A la ISO/IEC 9945-1, ANSI/IEEE Std 1003.1, 2004 Edition, ** with core dump avoidance. */ char * asctime(timeptr) register const struct tm * timeptr; { /* ** Big enough for something such as ** ??? ???-2147483648 -2147483648:-2147483648:-2147483648 -2147483648\n ** (two three-character abbreviations, five strings denoting integers, ** three explicit spaces, two explicit colons, a newline, ** and a trailing ASCII nul). */ static char result[3 * 2 + 5 * INT_STRLEN_MAXIMUM(int) + 3 + 2 + 1 + 1]; return asctime_r(timeptr, result); }
"Olson, Arthur David (NIH/NCI)" <olsona@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-gr...>.
** 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.
** 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.
might there not also be locale issues here? -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" werdna@squooshy.com * "information is power -- share the wealth."
participants (3)
-
Andrew Brown -
Olson, Arthur David (NIH/NCI) -
Paul Eggert