[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

["burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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."