This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/71218] Add a warning about "new T[integer-literal]"
- From: "egallager at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 05 Apr 2018 01:29:27 +0000
- Subject: [Bug c++/71218] Add a warning about "new T[integer-literal]"
- Auto-submitted: auto-generated
- References: <bug-71218-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71218
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-04-05
CC| |egallager at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Marc Glisse from comment #1)
> > Can you be more specific? Do you mean people should have written:
> > T tab[8];
>
> Yes, exactly. I was fixing some code earlier today that used a dynamically
> allocated buffer of 8 chars and deleted it at the end of the function (but
> failed to do so on two early return paths). There was no reason it was done
> that way instead of using an automatic array, probably just someone who
> learnt to programme in Java and didn't know better.
>
> > instead? What if 8 or sizeof(T) is large?
>
> The case I looked at was char, it would probably be OK to only warn for
> scalar types, and for small array lengths (for some value of small).
>
> > If your "..." includes possible
> > writes to p, or if p escapes and "..." may throw, I guess that cancels the
> > warning? At some point the issue becomes similar to optimizing malloc to a
> > stack allocation.
>
> Part of the problem in the code I was fixing was that the "..." certainly
> could throw, and the delete never happened.
>
> But maybe the escape analysis is too tricky.
Worth trying anyways; confirmed that it could be worthwhile to add this
warning.