[Bug fortran/47552] CTIME: Valgrind warning "depends on uninitialised value"

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47552

--- Comment #7 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-03-15 15:26:05 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > If not before, perhaps something to fix when/if we change to use size_t for
> > string lengths, see http://gcc.gnu.org/wiki/LibgfortranAbiCleanup
> 
> Just as a remark: you're not going to use size_t, but the signed ssize_t,
> right?

I think the idea was to use the unsigned size_t. 

- size_t is the natural type for representing the size of a memory object in
bytes. There is no need for negative values, and SSIZE_MAX is smaller than the
largest possible object (=SIZE_MAX) (an obscure corner case, but still).

- size_t is what the C string.h functions use, which is used in the
implementation of various string handling functions in gfortran (in libgfortran
and code generated directly by the frontend). Using the same type might also
help mixed C/Fortran programs.

- size_t is what Intel Fortran uses

- Yes, Fortran itself does not have unsigned integers, but the string length
type is invisible to Fortran programs. The LEN intrinsic does return the string
length typecast to a signed integer kind depending on the optional KIND
argument, or to a default kind integer. Depending on whether the target
supports an integer kind > sizeof(size_t) it might be possible to represent all
possible string lengths, or then not. But IMHO this does not change the fact
that the correct type for the (Fortran invisible) string length is the unsigned
size_t. Also, consider that at the asm level, typecasting from an unsigned to a
signed value of the same size is a no-op, so there is no efficiency loss.