From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120859 invoked by alias); 19 Jun 2017 18:44:55 -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 120838 invoked by uid 89); 19 Jun 2017 18:44:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,URIBL_SBL autolearn=ham version=3.3.2 spammy=HTo:D*cn, HTo:D*edu.cn X-HELO: mail-qt0-f181.google.com Received: from mail-qt0-f181.google.com (HELO mail-qt0-f181.google.com) (209.85.216.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Jun 2017 18:44:52 +0000 Received: by mail-qt0-f181.google.com with SMTP id w1so116837764qtg.2 for ; Mon, 19 Jun 2017 11:44:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2BQSE9/U6545v5118B4ZQu1Nm2CyNU6vdnJCcTsaiY4=; b=lFjVLxsirQJmDcBlX+YWU8rByFDEPNAYVSTw0y8a95K/BGmVqfbm0Wk9MlD8wiBszE jEYRm3HeGv0A0CyZpmj/M4c5UwLwZ39biPC6lWlc2Y1oMbGk61toc500D22brkzcLgte erU4hvitov7AZDNcrHhl7J4jNo3zK0ZCrn3Kyb7dxpb2Fx1kRypNclXXSHZygczHXghs lkwO+zAlgsgMffBj/T4s04RvuzCcTymuH1RX0UCiWht0hnIjlWLQLX0g0sILmJfAHgUr IFDHQM6MqomeWNDKcdeeMCIm0nwj0vrqluLdRG9hT63u78I1IP8oY6rdu+scGJr5YCK2 Xetw== X-Gm-Message-State: AKS2vOzcRzPX/eugQ6+EBURkW958GAtqZm/1w1+sMQ6TRf9wy3Ot9a5w SHOFUYy4dgexp0TL X-Received: by 10.200.55.27 with SMTP id o27mr29132320qtb.120.1497897895696; Mon, 19 Jun 2017 11:44:55 -0700 (PDT) Received: from localhost.localdomain (184-96-144-212.hlrn.qwest.net. [184.96.144.212]) by smtp.gmail.com with ESMTPSA id o76sm6728318qke.34.2017.06.19.11.44.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jun 2017 11:44:55 -0700 (PDT) Subject: Re: [PATCH 2/6] New warnings -Wstring-plus-{char, int} (PR c++/62181) To: Xi Ruoyao , gcc-patches@gcc.gnu.org References: <1497230800.27153.4.camel@stu.xidian.edu.cn> <1497231174.27153.9.camel@stu.xidian.edu.cn> <699bc809-8e5f-b908-7b2e-0dd036a09462@gmail.com> <1497893292.8943.1.camel@stu.xidian.edu.cn> From: Martin Sebor Message-ID: <7c4365db-fed6-f4c5-1231-2d8ac271fbe6@gmail.com> Date: Mon, 19 Jun 2017 18:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1497893292.8943.1.camel@stu.xidian.edu.cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg01366.txt.bz2 On 06/19/2017 11:28 AM, Xi Ruoyao wrote: > On 2017-06-19 10:51 -0600, Martin Sebor wrote: >> On 06/11/2017 07:32 PM, Xi Ruoyao wrote: >>> This patch adds warning option -Wstring-plus-int for C/C++. >>> >>> gcc/ChangeLog: >>> >>> 2017-06-12 Xi Ruoyao >>> >>> * c-family/c.opt: New option -Wstring-plus-int. >>> * c-family/c-common.c (pointer_int_sum): Checking for >>> -Wstring-plus-int. >> >> This is a very useful warning but I would suggest to word it >> in terms of what it actually does rather than what it might be >> intended to do. E.g., for >> >> const char *p = "123" + 7; >> >> issue >> >> warning: offset 7 exceeds the upper bound 3 of the array >> >> rather than >> >> warning: adding 'int' to a string does not append to the string >> >> (I have trouble envisioning on what grounds someone might expect >> the addition to have this effect.) > > How about something like `const char *p = "123" + getchar();` ? I'm not sure I correctly understand the question (or whether it's meant in response to my comment in parentheses) but let me clarify what I meant. In my view, the group of C++ (and certainly C) programmers who might expect "123" + i to append the string representation of the integer result to a string literal isn't significant enough to focus the warning on. Whether or not the addition is valid depends on the value of the integer operand. There are three sets of cases where the addition is or may be invalid: 1) the integer operand is an out of bounds constant 2) the integer operand's non-constant value or the lower bound of its range is known to be out of bounds, 3) the lower bound of the operand's range is in bounds but the upper bound is out of bounds (as in the getchar example). (1) can be handled with lexical analysis alone (as in you parch) but it's prone to a high rate of false negatives. (3) can also be handled by lexical analysis alone but it's prone to a high rate of false positives. (2) has no false positives but some false negatives. It can only be detected with optimization. With that in mind the warning would serve a greater purpose by being aimed more broadly and describing the nature of the error: forming an invalid pointer. I believe it would best be implemented analogously to or even integrated into -Warray-bounds. I.e., I suggest covering set (2) above. > > I'd like this for -Wstring-plus-int=1: > > warning: adding 'int' to a string does not append to the string > [-Wstring-plus-int=] > const char *p = "123" + 7; > ^ > note: offset 7 exceeds the size 4 of the string, using the result > may lead to undefined behaviour. The addition itself is undefined, regardless of whether or not the result is used. > > (Clang permits "123" + 4 since its result is well defined in standard. > Maybe we could permit "123" + 3 only.) "123" is an array of 4 elements, with "123" + 4 pointing just past the last (NUL) element. It's valid to form a pointer past the last element of an array and warning about it would likely be viewed as a false positive (certainly if it were an out-of-bounds type of warning). Martin