Patch to fix an undefined behavior in fortran/decl.c

[Qing Zhao]

Hi,

this is a very straightforward fix for an undefined behavior in fortran/decl.c:


In the man page of sprintf, it's clearly state:

===
NOTES
      Some programs imprudently rely on code such as the following

          sprintf(buf, "%s some further text", buf);

      to append text to buf.  However, the standards explicitly note that the  
results
      are  undefined if source and destination buffers overlap when calling 
sprintf(),
      snprintf(), vsprintf(), and vsnprintf().  Depending on  the  version  of  
gcc(1)
      used,  and  the compiler options employed, calls such as the above will 
not pro‐
      duce the expected results.
===

in gcc/fortran/decl.c, there is exactly such case as following:

3361       sprintf (name, "%s_%d", name, kind_value);

fixed it in this patch.

bootstraped and tested on both X86 and Aarch64. no regression.

Okay for trunk?

thanks.

Qing

====================================================
gcc/fortran/ChangeLog

2017-11-30  Qing Zhao  <qing.z...@oracle.com <mailto:qing.z...@oracle.com>>

       * fortran/decl.c (gfc_get_pdt_instance): Adjust the call to
       sprintf to avoid the same buffer being both source and
       destination.

---
gcc/fortran/decl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index e57cfde..02dda24 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -3358,7 +3358,7 @@ gfc_get_pdt_instance (gfc_actual_arglist *param_list, 
gfc_symbol **sym,
       }

      gfc_extract_int (kind_expr, &kind_value);
-      sprintf (name, "%s_%d", name, kind_value);
+      sprintf (name + strlen (name), "_%d", kind_value);

      if (!name_seen && actual_param)
       actual_param = actual_param->next;
-- 
1.9.1