use delete to destroy primitive/object types but memory is not freed

[jimjim]

Hello,

This is a simple question for you all, I guess .
int main(){
double *g= new double;
*g = 9;
delete g;
cout<< sizeof(g)<<" "<<sizeof(doubl e)<<" "<<sizeof(*g)<< " "<<*g<<" "<<endl;
*g = 111;
cout<< sizeof(g)<<" "<<sizeof(doubl e)<<" "<<sizeof(*g)<< " "<<*g<<" "<<endl;
return 0;
}

The output:
4 8 8 9
4 8 8 111

Although I delete g, why is it that I can still use it and it references to
actual memory?

The same happens when creating and deleting object types with new and
delete!

Please dont answer with what you think but with what actually happens. If
you can point me to web sources I can read on this, it would have been
great!

Thank you in advance.
Regards,
jimjim

[Michael Wojcik]

In article <ln************ @nuthaus.mib.or g>, Keith Thompson <ks***@mib.or g> writes:

mw*****@newsguy .com (Michael Wojcik) writes:

The C implmentations for the AS/400 can invalidate pointers in free(),
and indeed do so. Each C pointer is a descriptor that names an address
space and offset, and free() (after validating the descriptor) marks the
address space as invalid. Subsequent attempts to dereference a pointer
to the freed area cause a "trap"...

Question: does the AS/400's invalidation of pointers passed to free()
cause a trap when the pointer value itself is referenced (as in my
second example), or only when it's dereferenced (as in my first)?

To be honest, I don't remember, and I suspect it may depend on
circumstances. AIUI, use of an invalid pointer (whether it involves
dereferencing or simple referencing) is detected and rejected when
the OS/400 MI instruction "matptr" (materialize pointer) is executed.
(MI is the pseudo-assembly language that C and other customer-usable
languages compile to on the '400.)

The compiler generates a matptr for pointer dereferences, but I'm not
sure that it always does so for references.

Note that this also applies to Chris' post regarding pointer aliases.
In the case of:

p = malloc(size);
if (p)
{
q = p;
free(p);
r = q;
}

the '400 should trap that r=q if it does a matptr on q, since the
area named by q is no longer valid. But I don't know whether the
compiler will generate a matptr in this case.

I'll have to write some test programs and see. My AS/400 (which
lives in another state) appears to be down at the moment. (It's
configured to require operator intervention to reboot after a
power failure that outlasts the UPS, unfortunately. Must dig out
the docs and find out how to change that...)

--
Michael Wojcik mi************@ microfocus.com

Proverbs for Paranoids, 1: You may never get to touch the Master,
but you can tickle his creatures. -- Thomas Pynchon