Strange Output, Help.

[weichaoliu]

I know that this problem is concerned to GCC. But I hope somebody here
can tell me some detailed things about why.
The version of g++ I'm using is: g++ (GCC) 3.4.4 (mingw special).

The code is:
// BEGIN
#include<iostre am>

int main(void)
{
int *pI1 = new int;
int *pI2 = new int;
int *pI3 = new int;
int *pI4 = new int;
int *pI5 = new int;
int *pI6 = new int;
int *pI7 = new int;

*pI1 = 43;
*pI2 = 56;
*pI3 = 78;
*pI4 = 98;
*pI5 = 99;
*pI6 = 123;
*pI7 = 123;

std::cout << *pI1 << std::endl;
std::cout << *pI2 << std::endl;
std::cout << *pI3 << std::endl;
std::cout << *pI4 << std::endl;
std::cout << *pI5 << std::endl;
std::cout << *pI6 << std::endl;
std::cout << *pI7 << std::endl;

delete pI1;
delete pI2;
delete pI3;
delete pI4;
delete pI5;
delete pI6;
delete pI7;

std::cout << *pI1 << std::endl;
std::cout << *pI2 << std::endl;
std::cout << *pI3 << std::endl;
std::cout << *pI4 << std::endl;
std::cout << *pI5 << std::endl;
std::cout << *pI6 << std::endl;
std::cout << *pI7 << std::endl;

return 0;
} // END

The output is:
43
56
78
98
99
123
123
0
4013536
4013640
3998472
123
123

[weichaoliu]

After being deleted, the first value(*pI1) is ok. But the others
puzzled me a lot.
I've also compiled it under VC6.0. The result is "right".
I'm sure this is compiler specific. I just want to know how g++ in GCC
treat this.
I also tried:
// BEGIN
char *str = new char[0];
str = "gaga";
std::cout << *str << std::endl
<< str << std::endl;
delete [] str;
std::cout << *str << std::endl
<< str << std::endl;
// END
The output is puzzled too!

[Jay Nabonne]

On Thu, 29 Dec 2005 17:46:52 -0800, weichaoliu wrote:

I know that this problem is concerned to GCC. But I hope somebody here
can tell me some detailed things about why.
The version of g++ I'm using is: g++ (GCC) 3.4.4 (mingw special).

<snip offending code>

The problem isn't specific to GCC. The problem is in the code; it is
dereferencing pointers after they've been deleted. This is Undefined
Behavior, and anything can happen as a result (including "expected"
results).

The fix is Don't Do That.

- Jay

[Jay Nabonne]

On Thu, 29 Dec 2005 17:55:45 -0800, weichaoliu wrote:

After being deleted, the first value(*pI1) is ok. But the others
puzzled me a lot.
I've also compiled it under VC6.0. The result is "right".
I'm sure this is compiler specific. I just want to know how g++ in GCC
treat this.
I also tried:
// BEGIN
char *str = new char[0];
str = "gaga";
std::cout << *str << std::endl
<< str << std::endl;
delete [] str;
std::cout << *str << std::endl
<< str << std::endl;
// END
The output is puzzled too!

Once you return memory to the heap, you no longer own it. The memory
allocation routines can do whatever they want with it.

Again, the behavior is not defined per the standard, and no good can come
of doing it.

Just say no. :)

- Jay

[Jay Nabonne]

On Fri, 30 Dec 2005 02:04:47 +0000, Jay Nabonne wrote:

On Thu, 29 Dec 2005 17:55:45 -0800, weichaoliu wrote:

After being deleted, the first value(*pI1) is ok. But the others
puzzled me a lot.
I've also compiled it under VC6.0. The result is "right".
I'm sure this is compiler specific. I just want to know how g++ in GCC
treat this.
I also tried:
// BEGIN
char *str = new char[0];
str = "gaga";
std::cout << *str << std::endl
<< str << std::endl;
delete [] str;
std::cout << *str << std::endl
<< str << std::endl;
// END
The output is puzzled too!

Once you return memory to the heap, you no longer own it. The memory
allocation routines can do whatever they want with it.

Again, the behavior is not defined per the standard, and no good can come
of doing it.

Just say no. :)

Actually, consider this an alternate response to your first code.

This code exhibits a different problem. You're attempting to delete a
pointer you didn't allocate (you assign a different, non-allocated pointer
to "str"). That is yet another kind of undefined behavior. You're lucky it
didn't crash.

- Jay

[David Harmon]

On 29 Dec 2005 17:46:52 -0800 in comp.lang.c++, we********@gmai l.com
wrote,

delete pI1; std::cout << *pI1 << std::endl;

After 'delete' the pointer is invalid! Do not try to use it!!

[weichaoliu]

OKay, UNDEFINED BEHAVIOR.
So, I'm wondering about how GCC treats this kind of UNDEFINED BEHAVIOR.
I really do not like the answer ---- UNDEFINED BEHAVIOR. Can it solve
the problem? Or can it tell me the truth?
I'd always like to program under ISO/ANSI standards. Though ISO/ANSI
standards is perfect. I'm not working under such rules like ISO/ANSI
standards. I'm working in real world. ISO/ANSI standards are fantastic
on some aspects. ISO/ANSI standards are not everything! ISO/ANSI
standards come from real world!

If anybody wants to tell me that it's all about STANDARDS. Okay, I
appreciate your help.

But what I really want to know is what happened inside. Anybody know
that please tell me.

Thanks in advance!

/*
Becker
*/

[Greg]

we********@gmai l.com wrote:

OKay, UNDEFINED BEHAVIOR.
So, I'm wondering about how GCC treats this kind of UNDEFINED BEHAVIOR.
I really do not like the answer ---- UNDEFINED BEHAVIOR. Can it solve
the problem? Or can it tell me the truth?
I'd always like to program under ISO/ANSI standards. Though ISO/ANSI
standards is perfect. I'm not working under such rules like ISO/ANSI
standards. I'm working in real world. ISO/ANSI standards are fantastic
on some aspects. ISO/ANSI standards are not everything! ISO/ANSI
standards come from real world!

If anybody wants to tell me that it's all about STANDARDS. Okay, I
appreciate your help.

But what I really want to know is what happened inside. Anybody know
that please tell me.

I'm guessing that once the allocated memory had been freed, the OS or
compiler-runtime then stored some information about the freed block
within the block (such as its size, or a pointer to the next free block
or whatever) which would then account for the changed contents at that
memory location.

But as others have pointed out, it does not really matter why the
memory contents may or may not have changed since the result of
executing this program does not fall within the behavior defined by the
standard. Therefore the observed behavior in this case cannot be relied
on, may not in fact be repeatable, in short - it's useless and
uninteresting.

Greg

[Luke Meyers]

we********@gmai l.com wrote:

OKay, UNDEFINED BEHAVIOR.
So, I'm wondering about how GCC treats this kind of UNDEFINED BEHAVIOR.
I really do not like the answer ---- UNDEFINED BEHAVIOR. Can it solve
the problem? Or can it tell me the truth?
I'd always like to program under ISO/ANSI standards. Though ISO/ANSI
standards is perfect. I'm not working under such rules like ISO/ANSI
standards. I'm working in real world. ISO/ANSI standards are fantastic
on some aspects. ISO/ANSI standards are not everything! ISO/ANSI
standards come from real world!
Um... oh my god. Okay, listen carefully. In the Real World(tm), it is
a Very Bad Idea to attempt to use memory after you just deallocated it.
It's called undefined behavior because as soon as you delete the
memory, you are releasing your claim on it, and therefore can no longer
count on the guarantees that come with allocating it. "Undefined
behavior" is essentially a synonym for "random behavior," and writing
programs which behave randomly, especially with regard to reading and
writing memory, is neither safe nor interesting. That's why we avoid
it.

So, I don't know what you are referring to as "the problem" which you
would like solved. In this case, PEBKAC -- Problem Exists Between
Keyboard And Chair. That is to say, you shouldn't oughtta write code
like that, because it's meaningless and dangerous. The resolution to
the problem is not to delete the memory if you're still interested in
using it.
But what I really want to know is what happened inside. Anybody know
that please tell me.

A healthy curiosity is all well and good, but you're not going to get
particularly satisfying answers. The output you see when you read from
deallocated memory is unpredictable, and depends on the vagaries of the
runtime memory allocation system. Sometimes, it will just happen to
leave deallocated memory untouched for a while, which is the most
unfortunate circumstance because that makes it harder to track down the
problem. I suppose you could devise some kind of experiment to try and
learn about the behavior of the memory manager by trial and error,
but... why? Sure, it's neat. If you're really interested... it's open
source, so go read about how it works directly. My advice, though...
wait a bit on that if you want to actually comprehend it, and focus on
writing code that doesn't dump core at random intervals.

Cheers,
Luke

[Ron Natalie]

David Harmon wrote:

On 29 Dec 2005 17:46:52 -0800 in comp.lang.c++, we********@gmai l.com
wrote,

delete pI1;

std::cout << *pI1 << std::endl;

After 'delete' the pointer is invalid! Do not try to use it!!

even
std::couit << (void*)pI1 ;
is undefined behavior.