public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Xi Ruoyao <ryxi@stu.xidian.edu.cn>
To: Martin Sebor <msebor@gmail.com>, gcc-patches@gcc.gnu.org
Cc: ryxi@stu.xidian.edu.cn
Subject: Re: [PATCH 2/6] New warnings -Wstring-plus-{char, int} (PR c++/62181)
Date: Mon, 19 Jun 2017 19:36:00 -0000	[thread overview]
Message-ID: <1497900977.20950.1.camel@stu.xidian.edu.cn> (raw)
In-Reply-To: <7c4365db-fed6-f4c5-1231-2d8ac271fbe6@gmail.com>

On 2017-06-19 12:44 -0600, Martin Sebor wrote:
> 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  <ryxi@stu.xidian.edu.cn>
> > > > 
> > > > 	* 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.

Now I think I've been cheat by GCC wiki, which states PR 62181
is an "easy-hack" :)

I'll try to improve -Warray-bounds.

> > 
> > 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
-- 
Xi Ruoyao <ryxi@stu.xidian.edu.cn>
School of Aerospace Science and Technology, Xidian University

  reply	other threads:[~2017-06-19 19:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-12  1:26 [PATCH 0/6] " Xi Ruoyao
2017-06-12  1:31 ` [PATCH 1/6] " Xi Ruoyao
2017-06-12  1:32 ` [PATCH 2/6] " Xi Ruoyao
2017-06-19 16:51   ` Martin Sebor
2017-06-19 17:28     ` Xi Ruoyao
2017-06-19 18:44       ` Martin Sebor
2017-06-19 19:36         ` Xi Ruoyao [this message]
2017-06-22 10:26         ` Xi Ruoyao
2017-07-15 16:33           ` Gerald Pfeifer
2017-06-12  1:34 ` [PATCH 3/6] " Xi Ruoyao
2017-06-19 16:30   ` Martin Sebor
2017-06-19 17:35     ` Xi Ruoyao
2017-06-12  1:36 ` [PATCH 4/6] " Xi Ruoyao
2017-06-12  1:39 ` [PATCH 5/6] " Xi Ruoyao
2017-06-12  1:39 ` [PATCH 6/6] " Xi Ruoyao
2017-06-19 16:57   ` Martin Sebor
2017-06-19 12:43 ` [PING PATCH 0/6] " Xi Ruoyao
2017-06-19 16:20 ` [PATCH " Martin Sebor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1497900977.20950.1.camel@stu.xidian.edu.cn \
    --to=ryxi@stu.xidian.edu.cn \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=msebor@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).