public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: Andrew Briand <atb8888@comcast.net>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: GSoC Static Analysis
Date: Fri, 27 Mar 2020 09:01:54 +0000	[thread overview]
Message-ID: <CAH6eHdQxi10DapaK67K4cmAVFwYa4tGKVavh+Kwduo1GN2w0rQ@mail.gmail.com> (raw)
In-Reply-To: <20200325223732.74127385E01C@sourceware.org>

On Wed, 25 Mar 2020 at 22:38, Andrew Briand wrote:
>
> Hello,
>
> I am an undergrad interested in extending GCC’s static analysis pass for GSoC 2020. In particular, I’m interested in adding C++ support.
>
> The selected project ideas list mentions adding new/delete checking and exception checking. The features that immediately come to my mind would be checking for undeleted allocations, mixing delete and delete[], double deletion (it seems the current static analyzer already checks for double free), and uncaught exceptions.

I'm not sure reporting about uncaught exceptions is useful, except in
the (unlikely) case where the entire program is visible to the
compiler, or maybe as an extension of the -Wterminate warning.
Exceptions are *supposed* to be uncaught in most code, so they
propagate to a layer that can actually do something about the error.

Some other ideas for C++ code could be:

- Locking a mutex twice, or locking it and not unlocking it in the same scope.

- Locking and unlocking a mutex around a region with no side effects
(i.e. no I/O, no volatile read/writes, no atomic operations on
non-local variables).

- Using a shared_ptr where there's only a single owner so unique_ptr would work.

- Returning a reference/pointer to a local variable through another
function (which the current -Wreturn-local-addr warning can't
diagnose) e.g.
int& f(int& i) { return i; }
int& g() { int i = 0; return f(i); }

  parent reply	other threads:[~2020-03-27  9:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200325223732.74127385E01C@sourceware.org>
2020-03-27  1:42 ` David Malcolm
2020-03-27  9:01 ` Jonathan Wakely [this message]
2020-03-25 22:36 Andrew Briand
  -- strict thread matches above, loose matches on Subject: below --
2020-03-25 22:36 Andrew Briand
2020-03-25 22:36 Andrew Briand

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=CAH6eHdQxi10DapaK67K4cmAVFwYa4tGKVavh+Kwduo1GN2w0rQ@mail.gmail.com \
    --to=jwakely.gcc@gmail.com \
    --cc=atb8888@comcast.net \
    --cc=gcc@gcc.gnu.org \
    /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).