delete pointers: why is this working!!??

[mufasa]

i believe deleting an already delete pointer should give me a
segmentation fault! Why, then, is the following working? I am using gcc
version 3.0.2.

#include<stdio. h>
#include <string>
using namespace std;

int main()
{
string * j = new string("this prog should dump core!");
printf("\n%s\n" ,j->c_str());
delete j;
delete j;
}

[Alf P. Steinbach]

* mufasa:

i believe deleting an already delete pointer should give me a
segmentation fault! Why, then, is the following working? I am using gcc
version 3.0.2.

#include<stdio. h>
#include <string>
using namespace std;

int main()
{
string * j = new string("this prog should dump core!");
printf("\n%s\n" ,j->c_str());
delete j;
delete j;
}

It's Undefined Behavior, which means that any result whatsoever is
acceptable as far as the standard is concerned.

General advice as you're learning the language:

1) Don't use raw pointers.
2) Don't use raw pointers.
3) Don't ... You get the idea.

Also, consider using C++ iostreams, which are more type-safe than C printf.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Rolf Magnus]

mufasa wrote:

i believe deleting an already delete pointer should give me a
segmentation fault!
No, it should give you undefined behavior.
Why, then, is the following working?
Because that is one instance of "undefined behavior".
I am using gcc version 3.0.2.

#include<stdio. h>
#include <string>
using namespace std;

int main()
{
string * j = new string("this prog should dump core!");
printf("\n%s\n" ,j->c_str());
delete j;
delete j;
}

[Kehuei Huang]

the std::string class might've used a reference counting allocation for the
actually string content. The reference counting rule can be "delete the
content if reference count drops to zero; if the reference count is
negative, don't do any deletion".

you should refer to the actually implementation to see what is going on
there.

don't do double deletion, that's all.

"mufasa" <so*****@gmail. com> wrote in message
news:11******** **************@ l41g2000cwc.goo glegroups.com.. .

i believe deleting an already delete pointer should give me a
segmentation fault! Why, then, is the following working? I am using gcc
version 3.0.2.

#include<stdio. h>
#include <string>
using namespace std;

int main()
{
string * j = new string("this prog should dump core!");
printf("\n%s\n" ,j->c_str());
delete j;
delete j;
}

[Krishanu Debnath]

[top posting fixed]

Kehuei Huang wrote:

"mufasa" <so*****@gmail. com> wrote in message
news:11******** **************@ l41g2000cwc.goo glegroups.com.. .

i believe deleting an already delete pointer should give me a
segmentatio n fault! Why, then, is the following working? I am using gcc
version 3.0.2.

#include<stdi o.h>
#include <string>
using namespace std;

int main()
{
string * j = new string("this prog should dump core!");
printf("\n%s\n" ,j->c_str());
delete j;
delete j;
}

the std::string class might've used a reference counting allocation

for the actually string content. The reference counting rule can be "delete the
content if reference count drops to zero; if the reference count is
negative, don't do any deletion".
I don't see how your /proposed/ reference counting avoid undefined
behavior, when you are deleting the pointer j twice.

you should refer to the actually implementation to see what is going on
there.

don't do double deletion, that's all.

Krishanu

[joe.els]

Krishanu Debnath wrote:

[top posting fixed]

Kehuei Huang wrote:

"mufasa" <so*****@gmail. com> wrote in message
news:11******** **************@ l41g2000cwc.goo glegroups.com.. .

i believe deleting an already delete pointer should give me a
segmentatio n fault! Why, then, is the following working? I am using gccversion 3.0.2.

#include<stdi o.h>
#include <string>
using namespace std;

int main()
{
string * j = new string("this prog should dump core!");
printf("\n%s\n" ,j->c_str());
delete j;
delete j;
}

> the std::string class might've used a reference counting allocation for the

> actually string content. The reference counting rule can be

"delete the > content if reference count drops to zero; if the reference count is > negative, don't do any deletion".

I don't see how your /proposed/ reference counting avoid undefined
behavior, when you are deleting the pointer j twice.

>
> you should refer to the actually implementation to see what is going on > there.
>
> don't do double deletion, that's all.

Krishanu

[joe.els]

Hi

Sorry about the previous "empty" message.

I'm using glibc-2.3.4 with gcc-3.3.5.
When I do delete twice my program aborts:
"*** glibc detected *** double free or corruption (fasttop): 0x08049db0
***
Aborted"

I didn't expect such a descriptive error message.

Anyway, new and delete are merely mechanisms of telling the system,
which sections of memory you're using.
After calling the delete operator on a pointer, the memory pointed to
becomes available to the system again. Until the system reasigns that
memory you'll be able to "access" it.
ie:
int& a = new int;
a = 5;
cout << a; // "5"
delete &a;
cout << a; // "5"
.... // some time later
cout << a; // whatever's in memory at that time.
It is posible that having the two delete statements next to each other,
would allow your program to run without any problems.

Remember new and delete are class (static) operators not instance
operators.
It is posible to call them with out having any valid instances.

Also if you have to use raw pointer, set them to null after calling the
delete, then you'll be able to tell if it's safe to use.
IE:
SomeClass* sc = new SomeClass();
.... // some time later
if (sc) // true
{
sc->someFunction() ;
}
.... // some time later
if (sc) // true
{
delete sc;
sc = 0;
}
.... // some time later
if (sc) // false
{
sc->someFunction() ;
}

Joe

[mufasa]

How about this code? Is the delete statement here trying to break some
ownership rules (I think that's the case .. still verifying)?
Because this segment is dumping core as well!

#include<stdio. h>
#include <string>
using namespace std;

int main()
{
string someString("abc ");
char * c= new char[someString.leng th()];

c = const_cast<char *>(someString.c _str());

printf("\n%s\n" ,c);
delete [] c;
}

[Krishanu Debnath]

jo*****@dariel. co.za wrote:

Hi

Sorry about the previous "empty" message.
Post with proper context/quote is much appreciated.

I'm using glibc-2.3.4 with gcc-3.3.5.
[all compiler/implementation specific details snipped]
After calling the delete operator on a pointer, the memory pointed to
becomes available to the system again. Until the system reasigns that
memory you'll be able to "access" it.
ie:
int& a = new int;
[invalid c++ code fragments snipped]


It is posible that having the two delete statements next to each other,
would allow your program to run without any problems.

After invoking UB, it can run without any problems, it may also order
a 'peppy paneer pizza' from Pizza Hut for you. Best of luck !

Krishanu

[Rolf Magnus]

mufasa wrote:

How about this code? Is the delete statement here trying to break some
ownership rules (I think that's the case .. still verifying)?
Because this segment is dumping core as well!

#include<stdio. h>
#include <string>
using namespace std;

int main()
{
string someString("abc ");
char * c= new char[someString.leng th()];
Here, you allocate an array of 3 char and assign its starting address to c.
c = const_cast<char *>(someString.c _str());
Here, you overwrite c, losing the only pointer you had to your dynamically
allocated array. This is a memory leak. Also, the const_cast is a *very*
bad idea, as are almost all const_casts.
printf("\n%s\n" ,c);
delete [] c;
Here, you try to delete the array that was returned by c_str(), so the
answer to your question is yes, you break an ownership rule. You don't even
know whether the pointer returned by c_str() actually points to dynamically
allocated memory.
}