https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355
--- Comment #14 from Jonathan Wakely ---
(In reply to David Malcolm from comment #13)
> (In reply to Jonathan Wakely from comment #10)
>
> [...snip...]
>
> > As already noted above, new can't return null here, and there is no
> > dereference an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355
--- Comment #13 from David Malcolm ---
(In reply to Jonathan Wakely from comment #10)
[...snip...]
> As already noted above, new can't return null here, and there is no
> dereference anyway. And the pointer isn't leaked, but it seems maybe the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355
--- Comment #12 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #11)
> Ideally it would have complained when we copied the pointer value in the
> trivial copy constructor and didn't zero out the original. That shallow copy
> wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355
--- Comment #11 from Jonathan Wakely ---
If we add a real bug (making a shallow copy of the object, which shares the
same heap pointer and then both destructors free the same one):
struct S {
S() { p = new int(); }
~S() { delete p; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355
--- Comment #10 from Jonathan Wakely ---
struct S {
S() { p = new int(); }
~S() { delete p; }
int* p = nullptr;
};
int main() {
S s;
}
Everything the analyzer says is wrong :-)
dest.C: In function ‘int main()’:
dest.C:9:1: war
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355
--- Comment #9 from Jonathan Wakely ---
(In reply to William Navarre from comment #8)
> It seems that `operator new` is generally not supposed to return NULL --
> std::bad_alloc() is supposed to be thrown instead.
If an operator new overload is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355
William Navarre changed:
What|Removed |Added
CC||navarre.gcc.bugs at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355
--- Comment #7 from Ivan Sorokin ---
For me the support for operator new works well for trivially constructible
types. For a non-trivially constructible type I got a false positive:
struct foo { foo(); };
int main()
{
delete new foo();
}
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355
--- Comment #6 from Ivan Sorokin ---
I played with -fanalyzer on godbolt (GCC trunk). I noticed that -fanalyzer
doesn't report double free in this (convoluted) case:
#include
int main()
{
int* p = new int;
delete p;
free(p);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355
--- Comment #5 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:d4a906e7b51f3fc31f3328810f45ae4cf2e7bbc3
commit r11-3472-gd4a906e7b51f3fc31f3328810f45ae4cf2e7bbc3
Author: David Malcolm
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355
--- Comment #4 from David Malcolm ---
(In reply to Ivan Sorokin from comment #0)
> At the moment static analyzer warns about leaked malloc. It would be great
> if C++ new expression were also supported.
>
> Example:
>
> void f()
> {
> char*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:1690a839cff2e0276017a013419d81d675bbf69d
commit r11-3090-g1690a839cff2e0276017a013419d81d675bbf69d
Author: David Malcolm
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355
--- Comment #1 from Jonathan Wakely ---
This is already being actively discussed, and will probably be a GSoC project.
14 matches
Mail list logo
