On 03/01/2011 10:26 PM, Janne Blomqvist wrote:
Ok for trunk?
@code{CTIME} converts a system time value, such as returned by
-@code{TIME8}, to a string of the form @samp{Sat Aug 19 18:13:14 1995}.
+@code{TIME8}, to a localized string. Unless the application has called
+@code{setlocale}, the output will be in the default locale, of length
+24 and of the form @samp{Sat Aug 19 18:13:14 1995}. In other locales,
+a longer string may result.
I would suggest to remove the first "localized" - it gives too much
focus on the localization, which is usually not happening. (Side remark:
As it is a kind=1 string, certain localizations are not really possible
or in UTF-8 cause string-length issues.)
You should mention that - in case of the subroutine version - the RESULT
will be blank if the string does not fit.
+default kind. It is an @code{INTENT(OUT)} argument. If the length of
+this variable is too short for the localized date and time string to
+fit completely, it will be empty on procedure return.
I think you should scratch the "localized" here and use the wording from
ctime. Additionally, "empty" is not really a concept of a string. I
think you should use the word "blank". (The word "empty" fits better
for the result variable which would be is a string of length 0.)
(The repetition of the ctime wording might sound superfluous, but most
readers directly jump to the function, not knowing the ctime wording
when looking for ftime.)
@item @emph{Return value}:
-The current date as a string.
+The current date and time as a localized string. If the
+@code{CHARACTER} variable to which the result is assigned is too
+short, the result is truncated.
Again, I would leave out the "localized" here - and only mention it
together with setlocale in the Description. I am also not sure one needs
the words about truncation as this is a general concept of string
assignment. (Additionally, it is not quite true: Instead of truncation
also a reallocation with the right size could happen - for allocatable
"len=:" strings.)
With the nits fixed - or at least considered, the patch is OK. Thanks
for working on thread safety.
Tobias
2011-03-01 Janne Blomqvist<j...@gcc.gnu.org>
PR libfortran/47802
* gcc/fortran/intrinsics.texi: Update CTIME and FDATE
documentation.