I run into the following problem with LEN() function returning a wrong value for an allocated CHARACTER string after an assignment. Short Example:
CHARACTER(:), ALLOCATABLE :: cStr
INTEGER :: N = 32, iLen
ALLOCATE(CHARACTER(N) :: cStr)
iLen = LEN(cStr) ! = 32 (OK)
cStr = '13 characters'
iLen = LEN(cStr) ! = 13 (NOT OK)
I have tested this under Win7 IFORT 188.8.131.52 and Win10 with IFORT 184.108.40.2064, on both platforms IA-32 and x64 .
To me, this appears to be a bug. Am I wrong?
(working for Intel Elite Resellers qtsoftware.de and polyhedron.com)
allocate LHS (left hand side) came in at Fortran 2003(?) so your assignment reallocates the string to 13 chars. If you want the old standard behaviour there is a compiler option for that.
Re: your comment upthread, "That option does not apply to allocatable deferred-length character, which was new in F2008" - I do not think that is accurate.
Fortran 2003 introduced support for both deferred length objects (including scalar) of CHARACTER intrinsic type and the intrinsic assignment semantics of allocation (or reallocation) of variable to conform to 'expr' including that for deferred length scalar objects of CHARACTER intrinsic type.
Readers can look up Note 7.35 in section 220.127.116.11 Interpretation of intrinsic assignments in the 2003 standard document.
@FortranFan , yes, you are correct. This is indeed a F2003 feature. Nonetheless, I am also correct that the ifort option /assume:realloc_lhs does not apply to deferred-length character. It did in an early beta at one time, but I successfully argued at the time that this was a new feature and didn't warrant a "do it the old way" compatibility option.