public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Jason Merrill <jason@redhat.com>
Cc: Pedro Alves <palves@redhat.com>,
	Gcc Patch List <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] warn on mem calls modifying objects of non-trivial types (PR 80560)
Date: Fri, 02 Jun 2017 21:28:00 -0000	[thread overview]
Message-ID: <ce6557fb-94d8-0976-a8da-a5e9c5709cdf@gmail.com> (raw)
In-Reply-To: <cc62e93c-3b49-8e2f-70b9-acdd013fe760@redhat.com>

On 05/31/2017 05:34 PM, Jason Merrill wrote:
> On 05/27/2017 06:44 PM, Martin Sebor wrote:
>> +  /* True if the class is trivial and has a trivial non-deleted copy
>> +     assignment, copy ctor, and default ctor, respectively.  The last
>> +     one isn't used to issue warnings but only to decide what suitable
>> +     alternatives to offer as replacements for the raw memory
>> operation.  */
>> +  bool trivial = trivial_type_p (desttype);
>
> This comment seems out of date; there's only one variable here now.
>
>> +  /* True if the class is has a non-deleted trivial assignment.  Set
>
> s/is//
>
>> +  /* True if the class has a (possibly deleted) trivial copy ctor.  */
>> +  bool trivcopy = trivially_copyable_p (desttype);
>
> "True if the class is trivially copyable."
>
>> +      if (delassign)
>> +        warnfmt = G_("%qD writing to an object of type %#qT with "
>> +             "deleted copy assignment");
>> +      else if (!trivassign)
>> +        warnfmt = G_("%qD writing to an object of type %#qT with "
>> +             "no trivial copy assignment");
>> +      else if (!trivial)
>> +        warnfmt = G_("%qD writing to an object of non-trivial "
>> +             "type %#qT; use assignment instead");
>
> I'd still like the !trivial test to come first in all the memset cases,
> !trivcopy in the copy cases.

The tests are in the order they're in to provide as much useful
detail in the diagnostics as necessary to understand the problem
make the suggestion meaningful.  To what end you want to change
it?

AFAICS, all it will accomplish is shuffle the tests around
because starting with !trivial means I'll still need to test
for delassign and delcopy before issuing the warning so that
I can include the right suggestion (and avoid suggesting to
use assignment when it's not available).

>> +static bool
>> +has_trivial_special_function (tree ctype, special_function_kind sfk,
>> +                  bool *deleted_p)
>
> This seems redundant with type_has_trivial_fn.  If that function is
> giving the wrong answer for a class where all of the SFK are deleted,
> let's fix that, under check_bases_and_members, rather than introduce a
> new function.  I don't want to call synthesized_method_walk every time
> we want to check whether a function is trivial.

A deleted special function can be trivial.  type_has_trivial_fn()
only determines whether a function is trivial, not whether it's deleted. 
  I chose not to use the function because when a special
function is deleted I don't want to have the warning suggest it
as an alternative to the raw memory function.

Maybe I should use a different approach and instead of trying
to see if a function is deleted use trivially_xible to see if
it's usable.  That will mean changing the diagnostics from
"with a deleted special function" to "without trivial special
function" but it will avoid calling synthesized_method_walk
while still avoiding giving bogus suggestions.

Is this approach acceptable?

Martin

  parent reply	other threads:[~2017-06-02 21:28 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-29 22:10 Martin Sebor
     [not found] ` <alpine.DEB.2.20.1704302338540.1461@digraph.polyomino.org.uk>
2017-05-03 16:18   ` Martin Sebor
     [not found] ` <656ca1db-1082-b1ed-a911-ba7bf48f09c0@redhat.com>
2017-05-01 15:49   ` Jason Merrill
2017-05-11 20:03     ` Martin Sebor
2017-05-12  2:43       ` Martin Sebor
2017-05-17 11:53         ` Pedro Alves
2017-06-29 16:15       ` Jan Hubicka
2017-06-29 20:23         ` Martin Sebor
2017-06-29 22:34           ` Jan Hubicka
2017-06-30  0:16             ` Martin Sebor
2017-06-30  8:34           ` Richard Biener
2017-06-30 14:29             ` Martin Sebor
2017-07-04  9:33         ` Richard Earnshaw (lists)
2017-05-11 16:34   ` Martin Sebor
2017-05-11 16:57     ` Jakub Jelinek
2017-05-11 17:17       ` Martin Sebor
2017-05-16 19:46     ` Jason Merrill
2017-05-16 22:28       ` Martin Sebor
2017-05-19 19:14         ` Jason Merrill
2017-05-19 21:11           ` Martin Sebor
2017-05-19 21:56             ` Jason Merrill
2017-05-22  2:07               ` Martin Sebor
2017-05-22  6:07                 ` Jason Merrill
2017-05-24 20:28                   ` Martin Sebor
2017-05-24 20:48                     ` Martin Sebor
2017-05-24 21:36                       ` Jason Merrill
2017-05-28  5:02                         ` Martin Sebor
     [not found]                           ` <cc62e93c-3b49-8e2f-70b9-acdd013fe760@redhat.com>
2017-06-02 21:28                             ` Martin Sebor [this message]
2017-06-05  2:02                               ` Jason Merrill
2017-06-05  7:53                                 ` Jason Merrill
2017-06-05 16:07                                   ` Martin Sebor
2017-06-05 19:13                                     ` Martin Sebor
2017-06-06  1:53                                       ` Martin Sebor
2017-06-06 22:24                                         ` Martin Sebor
2017-06-08  1:09                                           ` Jason Merrill
2017-06-08 20:25                                             ` Martin Sebor
2017-06-12 21:36                                               ` Jason Merrill
2017-06-15 16:26                                                 ` Martin Sebor
2017-06-15 21:31                                                   ` Jason Merrill
2017-06-16  7:38                                                     ` Richard Biener
2017-06-16  7:40                                                       ` Richard Biener
2017-05-17  1:01       ` Pedro Alves
2017-05-17  1:57         ` Martin Sebor
2017-05-17 11:23           ` Pedro Alves
2017-07-05 20:58   ` Andrew Pinski
2017-07-05 22:33     ` 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=ce6557fb-94d8-0976-a8da-a5e9c5709cdf@gmail.com \
    --to=msebor@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=palves@redhat.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).