Observation on IDE Debugger

[ivfuser]

This is not a bug report or a feature request, per se. This is posted in the hope that it helps someone else.

Using the IVF 8.1.030 integration for DevStudio .NET 2002, I find that the IDE debugger does not represent CHARACTER data the way I might have expected. Or, does it?

If I build a CHARACTER variable with an embedded null, the debugger treats the value of the variable as if the null were a terminal delimiter, notwithstanding the facts that len_trim() gives the correct length and PRINT actually prints reasonably, i.e., the entire variable with the embedded null interpretated as an ASCII blank.

So far, this would not be so bad, except that the debugger display shows everything after the null as blank, up to and including the actual final character in the CHARACTER variable. This clearly need not be the case; ASCII characters may follow the null.

The following example shows the behavior:

program DebugStrings

implicit none

character(40) :: salutation
integer :: i

salutation = 'Hello World'
print *, salutation

i = len_trim( salutation )

salutation = salutation(:i) // '!'C
! debugger shows 'Hello World! '

print *, salutation

i = len_trim( salutation )

salutation = salutation(:i) // 'Hola!'
! debugger still shows 'Hello World! '

print *, salutation

i = len_trim( salutation ) ! gives 18, as expected

end program DebugStrings

This contrived example may not seem interesting, except insofar as it gives us a clue as to how the debugger is implemented. (Ok, that's still not very exciting.) But imagine the potential for confusion in a mixed-language context. That's how I actually stumbled into this.

Other non-printing characters, like newline, do not seem subject to the same interpretation as null; they simply appear as squares denoting non-printable characters in the debugger. Again, this tends to confirm the hint about the debugger implementation. Somethign had to be chosen as an internal delimiter. That's fine. But filling the rest of the declared variable length, post-null, with blanks is confusing.

Caveat scriptor!

[Steven_L_Intel1]

Please file this as a bug report with Intel Premier Support. I've seen this even back in CVF - I am pretty sure that it's the MS side of things that is truncating at the NUL since, of course, that's what C does. It's unclear to me what our "expression evaluator" could do, but maybe the folks who work on it can figure out something.

[ivfuser]

Thanks, and will do.