From patchwork Fri Dec 1 15:03:57 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Qing Zhao X-Patchwork-Id: 843530 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-468342-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="frVsoXNn"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3ypHc72gG8z9tB5 for ; Sat, 2 Dec 2017 02:04:23 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :mime-version:subject:message-id:date:cc:to:content-type :content-transfer-encoding; q=dns; s=default; b=mS08AyIqO3k2d+9F 9QqId0dfVitQNcr15iJfZVPnnc8XT8w2eZ5Ob+XRejDmGIGPx3olasg7hrlyLDeI alRzDRlePqSTORRuOwF/cVaanWgtWoLk3rIEKQV5C6JYGu5c0896vMP84dQrzXAZ P5SmWsfS31kDm7+gUPfy2RtfnXc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :mime-version:subject:message-id:date:cc:to:content-type :content-transfer-encoding; s=default; bh=RexIwVd1uTF/MqTXo1F5D4 X7290=; b=frVsoXNnkBmk/9oQMMKzRJs5JYW0RILgV21SqJz80mj5XFUuDZ5WUQ R3qjaMlTuf3zJ/6zMWQ9PhmefCSlx13nWz7gOcbRyL12qQgppXsEXcLj2YpsgLhG adp367UvSSRYXNHp9ZfCZQF7RhDckalASY/ROLDn65z6QEtSAf8gA= 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-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@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, 1 Dec 2017 09:03:57 -0600 Cc: fortran@gcc.gnu.org, blomqvist.janne@gmail.com, tkoenig@netcologne.de To: gcc-patches X-IsSubscribed: yes 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 > * 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;