Re: dereferencing memory location some time after deleting the same one

From: fabio de francesco (fmdf_at_tiscali.it)
Date: 10/21/04 

Date: 20 Oct 2004 17:27:37 -0700

Victor Bazarov <v.Abazarov@comAcast.net> wrote in message news:<Lsydd.5990$Ae.3850@newsread1.dllstx09.us.to.verio.net>...
> fabio de francesco wrote:
> > what do you think of the following? Why are we permitted to do that?
>
> Why not? The Standard says that any program that attempts to dereference
> a pointer after the pointer has been deleted, has undefined behaviour.
> An attempt to define what should happen in such case is a waste of time.

I am sorry for my English because sometimes I am not able to explain
what the it is the exact point of my question: I already know that the
behaviour is undefined as the Standard says. What I intended to ask is
why the Standard say that. I think that Standard would be better not
to allow dereferencing a pointer to deleted memory for the reasons I
wrote.

>
> > And why the C++ Library doesn't stop someone willing to perfom that
> > assignement (*a = 20)?
>
> How would it "stop" you?

Ok, let me try a way. I don't have enough IT competence to suggest the
best solution but I start from knowing that the Library takes pages of
memory from the kernel VM and manages the allocation of little pieces
of that to programs requiring bits of that memory. Is it true, isn't
it? So the responsibility for finer allocation of memory is in charge
of the Library that eventually could mark deleted locations as
unavailable and recollect them. May be this is not the right way but I
just tried to answer your question.
  
> >
> >
> > #include <iostream>
> >
> > using std::cout;
> >
> > int main()
> > {
> > int *a = new int(10);
> > cout << *a << " " << a << '\n';
> > delete a;
> > *a = 20;
> > cout << *a << " " << a << '\n';
> > }
> >
> >
> > After compiling (with gcc-3.4.1 on Linux and with VC++ on XP as well):
> >
> > #./a.out
> > 10 0x9f6d008
> > 20 0x9f6d008
>
> Undefined behaviour. Anything is allowed to happen.
>
> >
> >
> > Maybe what is worse is that if you compile and run the above written
> > code without the line "*a = 20;" you get the following output:
> >
> > #./a.out
> > 10 0x9f6d008
> > 0 0x9f6d008
>
> Again, it really shows nothing. The behaviour of that code is
> not defined. It is allowed to produce _any_ output or no output
> whatsoever.

That has been said before.

>
> >
> > I didn't know that this is the behaviour until I read a post on
> > it.comp.lang.c++ from someone who didn't understand why He got the
> > printed list of all the nodes of a bin-tree with a "0" output at the
> > position of some previously deleted nodes. So He didn't realize that
> > He forgot to assign NULL to the parent pointer field addressing the
> > just deleted nodes (and unfortunatelly all the deleted nodes were leaf
> > ones).
>
> OK
>
> >
> > I think that if He had got a crash, dereferencing a pointer to
> > deallocated memory, He would had understood what was bad with his
> > cancelling algorithm.
>
> He could get a crash. Or he could get a thank-you note in the mail.
> Or he could get his hard drive formatted. Anything is allowed to
> happen.

I think it shouldn't be allowed to happen anything not specified, for
the sake of safety.

> >
> > So wouldn't it be better if a program crashed when someone tried to
> > dereference a pointer to deleted memory location?
>
> No, it wouldn't. Forcing the program to crash would require some
> special processing. Besides, requiring the program to crash would
> only permit creation of C++ programs for systems where "crash" is
> defined. What if the system _cannot_ (or must not) crash? Even
> debugging such system would be a problem.

I don't know. What does the standard defines when a program tries to
access a memory location allocated to another process?

> V

Thank you,

Fabio De Francesco

Relevant Pages

  • Re: A C++ Whishlist
    ... In the vast majority of member functions the first thing you will do ... If I feel it needs an extra check because it won't crash cleanly I may ... >> unless you also check the this pointer you aren't checking every ... The standard does not say "the this pointer cannot be NULL". ...
    (comp.lang.cpp)
  • Re: Copying pthread_t
    ... Where is this different from all the other functions in the standard? ... object is modified through one pointer while the other pointer is ... each 'pthread_t' could have some memory allocated to ... initialize a pthread_t is by one of the pthread_* functions like ...
    (comp.programming.threads)
  • Re: A C++ Whishlist
    ... >>Show me where it says that in the standard. ... >>pointer (because it's easy, and there may not be a more appropriate ... allowing member function calls from null pointers. ... > I will be able to find out much more about the crash then you will. ...
    (comp.lang.cpp)
  • Re: ARM/Linux: Is this a cross-compiler bug? ¡]memcpy doesnt work as expected)
    ... memory by casting a pointer from A to B. The compiler is ... pointers point to different memory. ... What the standard says is not relevant. ...
    (comp.arch.embedded)
  • Re: Garbage collection
    ... My bet is that it will incorrectly free pieces of allocated memory ... I think the standard also allows, under the right circumstances, ... For example, it's perfectly legal to take a pointer object, break its ...
    (comp.lang.c)