Date: Thu, 22 Jul 2004 10:30:47 -0400 From: "Olson, Arthur David (NIH/NCI)" <olsona@dc37a.nci.nih.gov> Message-ID: <75DDD376F2B6B546B722398AC161106C740265@nihexchange2.nih.gov> | Code in "asctime" such as... | ...never returns NULL and never (when applied to a "struct tm" derived from | a 64-bit time_t) overflows a 26-character buffer passed to asctime. | It does lose time-of-day information in the distant past and distant future. Please, don't do that, or anything like it. Every byte in that 26 byte buffer has a defined (very well known) meaning, and code that extracts fields from the asctime output by simply knowing the byte offsets of the relevant fields is (and has been for many years) very very common. So is the fact that the buffer is exactly 26 bytes (25 data and the terminating 0). Don't attempt to fix bugs in the interface of this function, or change it any way at all - for years outside -999..9999 do whatever you like (a NULL return is OK, I guess, though lots of code doesn't bother checking, at least the least evil of several possible evils) - but just truncating the year to the last 4 digits would do as well, just as long as those 4 byte locations are filled with the year number (code that just uses %ld is wrong, as it won't properly use a 4 byte wide field - which isn't a problem if we assume the value is never < 1900, of course, which old code did, but will be a problem if you're going to handle years < 1000). Sometime, someone, somewhere, can define a new function if they want (probably they never will, since strftime() is a perfectly good replacement for asctime for any new uses) and alter the output format. But that can't be asctime(). And note here, I don't care in the slightest what the standards say for this - asctime and the format of that 26 character buffer is one of the oldest, and most stable, infertaces in all of unix - since it was invented, it has never altered, in any unix variant. Fortunately the standards makers also seem to understand this - which is why the day & month names are always the English abbreviations, no matter what the locale is, etc. kre