https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65089
--- Comment #11 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to Jerry DeLisle from comment #8)
> > True, fortran strings are not generally NULL terminated. However, for
> > internal representation between Frontend and library we try to do so for
> > safety. Evidently missed one or don't have it in this case. Still odd that
> > my manual, so to speak, 'for' loop is finding a NULL and counting the
> > correct length. I will do some more digging, probably something "obvious".
> > Just not seeing it yet.
>
> Has libgfortran been compiled with -fsanitize=address, or just the testcase?
> If the for loop is in the library that has not been instrumented, it is
> obvious why it doesn't trigger, while if you call strlen there and it is
> emitted as a library call, then it is intercepted by libasan and thus is
> instrumented. And the global variable (string literal) strlen is called on
> resides in the executable and is instrumented there.
Thanks for this explanation, it makes perfect sense. Also, I have located the
problem. When we do internal string I/O (using a string instead of an actual
file) we bypass format string caching and skip creation of the null terminated
version of the format string. I am working on a patch.
format_cache_ok = !is_internal_unit (dtp);
--- snip ---
if (format_cache_ok)
{
char *fmt_string = xmalloc (dtp->format_len + 1);
memcpy (fmt_string, dtp->format, dtp->format_len);
dtp->format = fmt_string;
dtp->format[dtp->format_len] = '\0';
}
