free a based based variable

How do we test whether a based variable is freed or not after the free
statement. Actually I have written a program where I am freeing the
nodes of a linked list in a loop. But after freeing those when I am
trying to display the values again it is showing the previous values
except the first noe.

If anybody have any material relating to this please share with me.

Papu wrote:
> How do we test whether a based variable is freed or not after the free
> statement.

You can't. The closest you can come is to set any appropriate pointer
variables to NULL. Then, later, if the pointer is NULL, you'll know the
resource was freed.

> Actually I have written a program where I am freeing the
> nodes of a linked list in a loop. But after freeing those when I am
> trying to display the values again it is showing the previous values
> except the first noe.

Freeing them doesn't erase them, or make them inaccessible. They /may/
be erased, or otherwise overwritten, or made inaccessible, after being
freed, but it is not guaranteed whether or when any of these things may
happen. If you want them to be erased, erase them yourself before freeing.

In general, this is true of all languages. Free means free -- you're
giving the memory back to the system; what the system does with it
afterwards is none of your business.

--
John W. Kennedy
"The grand art mastered the thudding hammer of Thor
And the heart of our lord Taliessin determined the war."
-- Charles Williams. "Mount Badon"

Papu wrote:
> How do we test whether a based variable is freed or not after the free
> statement. Actually I have written a program where I am freeing the
> nodes of a linked list in a loop. But after freeing those when I am
> trying to display the values again it is showing the previous values
> except the first noe.
>
> If anybody have any material relating to this please share with me.

If I understand you, you're saying you can still access the BASED
variables after FREE? FREE doesn't make the memory inaccessible, it
just allows it to be reused later if necessary, therefore most likely
the data will still be there, even after it's freed.

Peter Flass wrote:

(snip)

> If I understand you, you're saying you can still access the BASED
> variables after FREE? FREE doesn't make the memory inaccessible, it
> just allows it to be reused later if necessary, therefore most likely
> the data will still be there, even after it's freed.

I had a program some years ago (many years ago) that used CONTROLLED
variables. It was accidentally freeing them and reallocating them in
exactly the same place such that I didn't notice the bug for a long
time. Then something changed...

-- glen

"Papu" <srbehera@gmail.com> wrote in message
news:d6283c63-5ca1-4fb3-8a27-dcd842418cf1@k39g2000hsf.googlegroups.com...
> How do we test whether a based variable is freed or not after the free
> statement. Actually I have written a program where I am freeing the
> nodes of a linked list in a loop. But after freeing those when I am
> trying to display the values again it is showing the previous values
> except the first noe.

You aren't able to display the values of nodes
after they have been freed. Once freed, the nodes
don't exist. (Their values remain in storage until
overwritten, however. But they are inaccessible.)

> If anybody have any material relating to this please share with me.

Any PL/I book dealing with linked lists should be of help.

robin wrote:
> "Papu" <srbehera@gmail.com> wrote in message
> news:d6283c63-5ca1-4fb3-8a27-dcd842418cf1@k39g2000hsf.googlegroups.com...
>> How do we test whether a based variable is freed or not after the free
>> statement. Actually I have written a program where I am freeing the
>> nodes of a linked list in a loop. But after freeing those when I am
>> trying to display the values again it is showing the previous values
>> except the first noe.
>
> You aren't able to display the values of nodes
> after they have been freed. Once freed, the nodes
> don't exist. (Their values remain in storage until
> overwritten, however. But they are inaccessible.)

That depends on the implementation. In some implementations, unless the
storage has been reallocated and values have been assigned to the new
allocation, if you keep a pointer to freed based storage it can
generally still be referred to and most of the value will still be
there. Some of the value may have been overlaid by control information
used by the storage allocator.

>
>> If anybody have any material relating to this please share with me.
>
> Any PL/I book dealing with linked lists should be of help.
>
>

"James J. Weinkam" <jjw@cs.sfu.ca> wrote in message news:OPvnj.44006$fj2.3065@edtnps82...
> robin wrote:
> > "Papu" <srbehera@gmail.com> wrote in message
> > news:d6283c63-5ca1-4fb3-8a27-dcd842418cf1@k39g2000hsf.googlegroups.com...
> >> How do we test whether a based variable is freed or not after the free
> >> statement. Actually I have written a program where I am freeing the
> >> nodes of a linked list in a loop. But after freeing those when I am
> >> trying to display the values again it is showing the previous values
> >> except the first noe.
> >
> > You aren't able to display the values of nodes
> > after they have been freed. Once freed, the nodes
> > don't exist. (Their values remain in storage until
> > overwritten, however. But they are inaccessible.)
>
> That depends on the implementation.

Once the object has been freed, consider it gone
forever. It is in error to try to reference the storage
area that it occupied.

> In some implementations, unless the
> storage has been reallocated and values have been assigned to the new
> allocation, if you keep a pointer to freed based storage it can
> generally still be referred to and most of the value will still be
> there. Some of the value may have been overlaid by control information
> used by the storage allocator.

Trying to do what you suggest is a recipe for disaster.

robin wrote:
> "James J. Weinkam" <jjw@cs.sfu.ca> wrote in message news:OPvnj.44006$fj2.3065@edtnps82...
>> robin wrote:
>>> "Papu" <srbehera@gmail.com> wrote in message
>>> news:d6283c63-5ca1-4fb3-8a27-dcd842418cf1@k39g2000hsf.googlegroups.com...
>>>> How do we test whether a based variable is freed or not after the free
>>>> statement. Actually I have written a program where I am freeing the
>>>> nodes of a linked list in a loop. But after freeing those when I am
>>>> trying to display the values again it is showing the previous values
>>>> except the first noe.
>>> You aren't able to display the values of nodes
>>> after they have been freed. Once freed, the nodes
>>> don't exist. (Their values remain in storage until
>>> overwritten, however. But they are inaccessible.)
>> That depends on the implementation.
>
> Once the object has been freed, consider it gone
> forever. It is in error to try to reference the storage
> area that it occupied.

Of course it's an error; I never said otherwise. But is also a fact
that with some implementations, I suspect most, a pointer to based
storage (or any other storage for that matter) that has been freed can
still address the memory and unless that memory has subsequently been
rellocated and had new values assigned it will continue to hold the
previous value. I am certainly not advocating doing this on purpose.
I'm just saying what is likely to happen if you do it inadvertently.
Since there is no reliable protection against it. it behooves
programmers to be careful.
>
>> In some implementations, unless the
>> storage has been reallocated and values have been assigned to the new
>> allocation, if you keep a pointer to freed based storage it can
>> generally still be referred to and most of the value will still be
>> there. Some of the value may have been overlaid by control information
>> used by the storage allocator.
>
> Trying to do what you suggest is a recipe for disaster.
>
>
You seem unable to distinguish between advocating doing something and
explaining what will happen if it is done unintentionally.

It is also possible that the storage has been reallocated and then
almost anything can happen depending on what has been assigned to the
new variables stored in those locations.

The point is that since most implementations do not ensure that attempts
to reference freed storage are guaranteed to fail, incorrect programs
frequently seem to work for many years then suddenly fail when some
seemingly unrelated circumstance changes.

"James J. Weinkam" <jjw@cs.sfu.ca> wrote in message news:C16oj.164$C61.92@edtnps89...
> robin wrote:
> > "James J. Weinkam" <jjw@cs.sfu.ca> wrote in message news:OPvnj.44006$fj2.3065@edtnps82...
> >> robin wrote:
> >>> "Papu" <srbehera@gmail.com> wrote in message
> >>> news:d6283c63-5ca1-4fb3-8a27-dcd842418cf1@k39g2000hsf.googlegroups.com...
> >>>> How do we test whether a based variable is freed or not after the free
> >>>> statement. Actually I have written a program where I am freeing the
> >>>> nodes of a linked list in a loop. But after freeing those when I am
> >>>> trying to display the values again it is showing the previous values
> >>>> except the first noe.
> >>> You aren't able to display the values of nodes
> >>> after they have been freed. Once freed, the nodes
> >>> don't exist. (Their values remain in storage until
> >>> overwritten, however. But they are inaccessible.)
> >> That depends on the implementation.
> >
> > Once the object has been freed, consider it gone
> > forever. It is in error to try to reference the storage
> > area that it occupied.
>
> Of course it's an error; I never said otherwise.

On the contrary, you implied that such objects could be
accessed as if it was normal.

> But is also a fact
> that with some implementations, I suspect most, a pointer to based
> storage (or any other storage for that matter) that has been freed can
> still address the memory and unless that memory has subsequently been
> rellocated and had new values assigned it will continue to hold the
> previous value. I am certainly not advocating doing this on purpose.
> I'm just saying what is likely to happen if you do it inadvertently.
> Since there is no reliable protection against it. it behooves
> programmers to be careful.
> >
> >> In some implementations, unless the
> >> storage has been reallocated and values have been assigned to the new
> >> allocation, if you keep a pointer to freed based storage it can
> >> generally still be referred to and most of the value will still be
> >> there. Some of the value may have been overlaid by control information
> >> used by the storage allocator.
> >
> > Trying to do what you suggest is a recipe for disaster.

> You seem unable to distinguish between advocating doing something and
> explaining what will happen if it is done unintentionally.

Your post made no such qualification, and as such
was bound to be interpreted by the OP as a feature
that could be utilised in programs, as that was the way
it worked.

Thanks a lot guys for your valuable answers to my query. Nice to know
something useful