public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Marek Polacek <polacek@redhat.com>
Cc: Jason Merrill <jason@redhat.com>,
	Gcc Patch List <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] have chkp skip flexible member arrays (PR #79986)
Date: Tue, 21 Mar 2017 23:56:00 -0000	[thread overview]
Message-ID: <100585c2-eff0-0f86-b55a-a42544a8ce0c@gmail.com> (raw)
In-Reply-To: <20170321154649.GN3172@redhat.com>

> Since I've also spent some time on this: my take on this is that the C++ FE
> should just follow C FE's suit and reject such initializations where
> possible; it seems they've never worked reliably anyway, and bring more
> harm than good.  I don't see that rejecting such code would cause too much
> trouble, if any, although the timing could be better.

Schedule concerns aside, and although I agree that rejecting such
code is far preferable to generating buggy programs, I'm not sure
that rejecting auto initialization of flexible array members will
ultimately lead to the best results.  Users who want to initialize
local objects with flexible array members will find some other
(likely convoluted) way that GCC may not be able to find bugs in.
A possible solution for those who can't or don't want to use
std::array might be something like this:

   void f ()
   {
     struct S { size_t n; int a[]; };

     S *ps = (S*)alloca (sizeof (S) + 5);

     ps->n = 5;
     memcpy (ps->a, (const int[]){ 1, 2, 3, 4, 5 }, sizeof *ps->a * 5);

     ...
   }

but that's clearly error-prone and hard to diagnose.  GCC has
no mechanism to detect bugs in this code without optimization,
and because it folds the memcpy into a bunch of assignments,
-Wstringop-overflow doesn't detect buffer overflows in the
call to the function.

I think it would be better to get the initialization to work so
that users don't have to jump through hoops and can instead write
cleaner code that more readily lends itself to checking for bugs.
It might be even worth proposing local initialization as
an enhancement for C2X.

Martin

  reply	other threads:[~2017-03-21 23:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-20 23:04 Martin Sebor
2017-03-20 23:51 ` Jason Merrill
2017-03-20 23:58   ` Martin Sebor
2017-03-21  4:27     ` Jason Merrill
2017-03-21 15:08       ` Martin Sebor
2017-03-21 15:15         ` Jakub Jelinek
2017-03-21 15:17           ` Jeff Law
2017-03-21 15:46         ` Marek Polacek
2017-03-21 23:56           ` Martin Sebor [this message]
2017-03-21 19:33         ` Jason Merrill
2017-03-29 23:29           ` Martin Sebor
2017-04-07 16:50             ` Jason Merrill

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=100585c2-eff0-0f86-b55a-a42544a8ce0c@gmail.com \
    --to=msebor@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=polacek@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).