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'; }