http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802
--- Comment #13 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-02-22 08:37:13 UTC --- FWIW here's a glibc PR wrt overflowing the 26 byte limit: http://sourceware.org/bugzilla/show_bug.cgi?id=1460 This was fixed in 2005, which is a while ago, but not long enough so it's completely unimaginable that someone would want to run gfortran on such a platform. For this particular glibc issue, a workaround is to make sure the buffer is at least 33 bytes. In any case, I'm thinking that Dave's suggestion to use strftime could work. Also, in addition to the autoconf manual recommending to avoid ctime/ctime_r, POSIX 2008 also marks those as obsolescent and recommends strftime instead. strftime appears to have well defined behavior for all kinds of time input and string lengths. And, using it would obviously also solve the problem of non-standard ctime_r implementations. strftime needs localtime_r, but we have already used that one without problems for quite a while (in the implementation of the DATE_AND_TIME intrinsic) so it shouldn't cause any further portability problems. The caveat is that if using a non-default locale the output is different. In practice, (lib)gfortran never calls setlocale so unless the application explicitly calls it a gfortran program runs in the "C" locale, in which case a suitable choice of format string guarantees identical output as ctime(). And, if the applications does call setlocale, outputting a localized string could be seen as a feature. (In reply to comment #6) > I guess the question we need to ask is how important are these routines > and should we be issuing warnings when they are used, much like is done > with gets. If we don't need them, I'd much prefer to see them go away > as they're a rats nest of security issues. Standard Fortran, as of Fortran 2008, supports 3 time related intrinsics; DATE_AND_TIME, SYSTEM_CLOCK, and CPU_TIME. Every other time intrinsic in gfortran is due to legacy g77 support, or some other widely used extension. If one compiles with one of the standards conformance options (-std=fxxxx) these other intrinsics are not available. Personally, I'd be happy to get rid of all the nonstandard time intrinsics, but some of our users might disagree..
