new[] not matched with delete[]

[Nick Keighley]

Yes I know, you're not supposed to do that.


new char a[10]
do_something();
delete a;

now is that a memory leak or is it that the DTORs aren't invoked or is
it simply Undefined Behaviour.

I ask because it's an existing code base and I wondered how urgent it
was that it got fixed?


This is obviously a memory leak

new std::string strs[10];
delete strs;

 

[James Kanze]

Yes I know, you're not supposed to do that.

new char a[10]
do_something();
delete a;

now is that a memory leak or is it that the DTORs aren't invoked or is
it simply Undefined Behaviour.

It's undefined behavior. On most implementations I know, it
will work if the type is a POD, but the language doesn't even
require this.

I ask because it's an existing code base and I wondered how urgent it
was that it got fixed?

This is obviously a memory leak

new std::string strs[10];
delete strs;

It's obviously undefined behavior. I've used systems on which
it would crash, for example, and systems on which it would
corrupt the free space arena, leading to a later crash. (And
systems on which it would behave differently, depending on
compiler options.)

 

[Stuart Golodetz]

Yes I know, you're not supposed to do that.


new char a[10]
do_something();
delete a;

now is that a memory leak or is it that the DTORs aren't invoked or is
it simply Undefined Behaviour.

I ask because it's an existing code base and I wondered how urgent it
was that it got fixed?


This is obviously a memory leak

new std::string strs[10];
delete strs;

It's all well and truly undefined behaviour, and as such it's an urgent
fix -- sorry to impart the bad news

Cheers,
Stu

 

[Nick Keighley]

Yes I know, you're not supposed to do that.

        new char a[10]
       do_something();
       delete a;

now is that a memory leak or is it that the DTORs aren't invoked or is
it simply Undefined Behaviour.

I ask because it's an existing code base and I wondered how urgent it
was that it got fixed?

This is obviously a memory leak

      new std::string strs[10];
     delete strs;

It's all well and truly undefined behaviour, and as such it's an urgent
fix -- sorry to impart the bad news

I suspected so, I was looking for more ammunition to use with other
people.

Most cases are simply buffers whose size isn't known at compile time.
Judicious use of std::vector might be a better idea.

 

[Victor Bazarov]

Yes I know, you're not supposed to do that.


new char a[10]
do_something();
delete a;

now is that a memory leak or is it that the DTORs aren't invoked or is
it simply Undefined Behaviour.

I ask because it's an existing code base and I wondered how urgent it
was that it got fixed?


This is obviously a memory leak

new std::string strs[10];

Does it even compile?

delete strs;

V

 

[Öö Tiib]

Yes I know, you're not supposed to do that.

       new char a[10]
      do_something();
      delete a;

now is that a memory leak or is it that the DTORs aren't invoked or is
it simply Undefined Behaviour.

I ask because it's an existing code base and I wondered how urgent it
was that it got fixed?

This is obviously a memory leak

     new std::string strs[10];
    delete strs;

Does not look like C++. Perhaps some context is missing without what i
can't parse what it does.

 

[Nick Keighley]

Yes I know, you're not supposed to do that.

       new char a[10]
      do_something();
      delete a;

now is that a memory leak or is it that the DTORs aren't invoked or is
it simply Undefined Behaviour.

I ask because it's an existing code base and I wondered how urgent it
was that it got fixed?

This is obviously a memory leak

     new std::string strs[10];
    delete strs;

Does not look like C++. Perhaps some context is missing without what i
can't parse what it does.

yes you are correct it's complete gibberish. Posting in a hurry (and I
don't new arrays in my own code!)

a = new int[n];

This is a link to a late 1998 draft standard (a hardcopy says the same
thing)
www.kuzbass.ru:8086/docs/isocpp/expr.html

*****
5.3.5 - Delete [expr.delete]
[... para 2 ...]
In the first alternative (delete object), the value of the operand of
delete shall be a pointer to a non-array object or a pointer to a sub-
object (intro.object) representing a base class of such an object
(clause class.derived). If not, the behavior is undefined.
[...]
In the second alternative (delete array), the value of the operand of
delete shall be the pointer value which resulted from a previous array
new-expression. [...] If not, the behavior is undefined.
*****