http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802
--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-21 18:08:13 UTC --- (In reply to comment #6) > Certain implementations pass in a buffer size > parameter to deal with that problem, others (glibc) presumably do some > checking before dumping results into the user supplied buffer to make > sure they don't exceed the 26 bytes or whatever the minimum size of hte > buffer is supposed to be. Baring implementation bugs I would claim that all two-argument ctime_r implementations should work with 26 byte arguments as POSIX has been defined as such: "The ctime_r() function shall convert the calendar time pointed to by clock to local time in exactly the same form as ctime() and put the string into the array pointed to by buf (which shall be at least 26 bytes in size) and return buf. Unlike ctime(), the thread-safe version ctime_r() is not required to set tzname." http://pubs.opengroup.org/onlinepubs/009695399/functions/ctime.html The definition goes back to POSIX (SUSv2) of February 1997 - and IEEE Std 1003.1c-1995. One should assume that within the last 15 years they vendors managed to get the 26-byte buffer issue correct ... (How to deal with a three-argument version is a separate question; different vendors have probably different arguments, though buflen could be a more common choice.) > I guess the question we need to ask is how important are these routines >From he non-normative part of POSIX: "The ctime_r() function is thread-safe and shall return values in a user-supplied buffer instead of possibly using a static data area that may be overwritten by each call."
