From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109776 invoked by alias); 1 Dec 2017 15:04:15 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 109756 invoked by uid 89); 1 Dec 2017 15:04:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-20.7 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,HTML_MESSAGE,KAM_LAZY_DOMAIN_SECURITY,KB_WAM_FROM_NAME_SINGLEWORD,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 spammy=H*c:alternative, H*c:MHil, H*c:HHHHHHHH, H*c:HHHH X-Spam-User: qpsmtpd, 2 recipients X-HELO: userp1040.oracle.com Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 01 Dec 2017 15:04:04 +0000 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vB1F40sO030372 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 1 Dec 2017 15:04:01 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vB1F3xpL015560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 1 Dec 2017 15:03:59 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vB1F3w5J028859; Fri, 1 Dec 2017 15:03:59 GMT Received: from dhcp-adc-twvpn-3-vpnpool-10-154-119-207.vpn.oracle.com (/10.154.119.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Dec 2017 07:03:58 -0800 From: Qing Zhao Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Patch to fix an undefined behavior in fortran/decl.c Message-Id: <47AB1118-E914-4ABB-BCE9-89A4C4867768@oracle.com> Date: Fri, 01 Dec 2017 15:04:00 -0000 Cc: fortran@gcc.gnu.org, blomqvist.janne@gmail.com, tkoenig@netcologne.de To: gcc-patches Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00045.txt.bz2 Hi, this is a very straightforward fix for an undefined behavior in fortran/dec= l.c: In the man page of sprintf, it's clearly state: =3D=3D=3D 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 t= he 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 wi= ll not pro=E2=80=90 duce the expected results. =3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D gcc/fortran/ChangeLog 2017-11-30 Qing Zhao > * 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 =3D actual_param->next; --=20 1.9.1