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.
