[Bug fortran/65089] FAIL: gfortran.dg/io_real_boz(2|_[45]).f90 when tested with -fsanitize=address

["jvdelisle at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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