free()

[dbansal]

Hi group,

I have a question to ask you all. I have allocated some chunk of
memory using ptr=(int*)malloc(). now I am trying to free that memory
using free((void*)ptr). My question is does free() make ptr NULL? If
not how do we know whether ptr memory has been freed already and we
should not try to free the same memory twice. Man pages does not tell
anything about this behavoiur.

Thanks,

[Christopher Layne]

Racaille wrote:

Please, let's stop this, it gets ridiculous. You still feign not to
get my point.
If you set it to NULL after very free(), then it could be just any
pointer
ever passed to free(), and so it is indeterminate from the point of
view of somebody trying to trace it.

On the flipside, what IS wrong with setting it to NULL? It's a very distinct
state change and you're arguing that the lack of that state change somehow
will make debugging easier - which I don't agree with personally. It will
result in an immediate failure upon use. How is this slower (besides using
external tools) to track down than not setting it to NULL?

As a debugger writer you should be well aware of watchpoints, tracepoints,
etc. which aren't going to care if the pointer is set to NULL or not.
Unfortunately in a lot of cases they are extremely slow.

[Richard Heathfield]

Racaille said:

On Feb 14, 3:14 pm, Richard Heathfield <[e-mail]:

Also, the value of the pointer may give someone who is debugging
the program
precious clue on where the value did come from

No, because inspecting the value is not allowed. The value is
indeterminate, and inspecting it invokes undefined behaviour.

- by setting it to NULL, you have made it indeterminate.

No, by setting it to NULL, you have made it determinate!

Please, let's stop this, it gets ridiculous.

Fine by me.

You still feign not to get my point.

I don't think you have one.

If you set it to NULL after very free(), then it could be just any
pointer ever passed to free(), and so it is indeterminate from the
point of view of somebody trying to trace it.

That's not what "indeterminate" means within the context of discussions
within this group. When we use the term "indeterminate", we mean that
the supposed value of an object has no meaning. NULL has a meaning -
it's a pointer value that is *guaranteed* not to point to any object,
and it can be meaningfully compared to another pointer value for
equality or inequality. And therein lies its value.

I know there may be machines where just 'inspecting' a invalid pointer
(without dereferencing it) is not possible, but this is irrelevant,

No, it isn't.

since as a debugger writer I am free to use whatever machine
dependencies

Yes, you are, but in *this* newsgroup we discuss machine-independent
code.

I like in order to track down bugs, and I am free to take advantage of
pointers being just bitmaps/long integers is this makes things
simpler.

You are also free to call dlopen() or SetWindowTitle(). That doesn't
make such things topical here.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Racaille]

On Feb 14, 4:01 pm, Christopher Layne <[e-mail]:

Racaille wrote:

Please, let's stop this, it gets ridiculous. You still feign not to
get my point.
If you set it to NULL after very free(), then it could be just any
pointer
ever passed to free(), and so it is indeterminate from the point of
view of somebody trying to trace it.

On the flipside, what IS wrong with setting it to NULL? It's a very distinct
state change and you're arguing that the lack of that state change somehow
will make debugging easier - which I don't agree with personally. It will

Setting it to NULL when not needed is a spurious state change, so it's
noise
and it makes debugging harder.

[Yevgen Muntyan]

Richard Heathfield wrote:

Racaille said:

>On Feb 14, 3:14 pm, Richard Heathfield <[e-mail]:

>>>Also, the value of the pointer may give someone who is debugging
the program
precious clue on where the value did come from
No, because inspecting the value is not allowed. The value is
indeterminate, and inspecting it invokes undefined behaviour.

- by setting it to NULL, you have made it indeterminate.
No, by setting it to NULL, you have made it determinate!

Please, let's stop this, it gets ridiculous.

Fine by me.

>You still feign not to get my point.

I don't think you have one.

>If you set it to NULL after very free(), then it could be just any
pointer ever passed to free(), and so it is indeterminate from the
point of view of somebody trying to trace it.

That's not what "indeterminate" means within the context of discussions
within this group. When we use the term "indeterminate", we mean that
the supposed value of an object has no meaning. NULL has a meaning -
it's a pointer value that is *guaranteed* not to point to any object,
and it can be meaningfully compared to another pointer value for
equality or inequality. And therein lies its value.

>I know there may be machines where just 'inspecting' a invalid pointer
(without dereferencing it) is not possible, but this is irrelevant,

No, it isn't.

>since as a debugger writer I am free to use whatever machine
dependencies

Yes, you are, but in *this* newsgroup we discuss machine-independent
code.

>I like in order to track down bugs, and I am free to take advantage of
pointers being just bitmaps/long integers is this makes things
simpler.

You are also free to call dlopen() or SetWindowTitle(). That doesn't
make such things topical here.

There you go. Final argument in "how to write code and why" is "tools
you are talking about are off-topic here". Or was it about "how to
debug strictly conforming programs using only standard tools and
techniques"? Not that I get that "using junk pointers makes debugging
easier" concept, but either the whole discussion is off-topic here
(which it is, isn't it) or you got to admit the fact that people write
code in real life sometimes, using some non-standard tools (debugger!).

Yevgen

[Christopher Layne]

Racaille wrote:

Setting it to NULL when not needed is a spurious state change, so it's
noise
and it makes debugging harder.

No, it's an explicit state change. Which means when it is used, you know
exactly where to find THE ERROR. What is difficult for you to understand
about this non-obtuse approach?

[Martin Ambuhl]

ra************@yahoo.co.in wrote:

This is Interesting..! I am just putting small code to check some
stuff.

[...]

char *p;
char*q;

p=(char *) malloc(100);

Are you being purposely obtuse? How many people need to tell you to
lose the obfuscating, error-prone, superfluous, and poor style cast of
the return value of malloc() before you pay attention?

/* I should do memset but ... */

No, you shouldn't, unless you just enjoy pointless waste of processing
time and pointless excessive typing.

>
strcpy(p,"raxit sheth");

q=p;

printf("\nP=%p : %s",p,p);

^^
but here you _should_ use a cast, since %p takes a pointer-to-void.
That 'void *' and 'char *' have the same form saves you here does not
change the fact that printing non-'void *' pointers with "%p" should be
cast.

printf("\nQ=%p :%s",q,q);
fflush(stdout);
free(p);
/* p=NULL; */

printf("\n AFTER FREE ");
printf("\nP=%p : %s",p,p);

^^
undefined behavior, since you are dereferencing a pointer not
pointing to allocated or declared memory. Your output is irrelevant.

[santosh]

Yevgen Muntyan wrote:

Richard Heathfield wrote:

Racaille said:

On Feb 14, 3:14 pm, Richard Heathfield <[e-mail]:
Also, the value of the pointer may give someone who is debugging
the program
precious clue on where the value did come from
No, because inspecting the value is not allowed. The value is
indeterminate, and inspecting it invokes undefined behaviour.

<snip>

I know there may be machines where just 'inspecting' a invalid pointer
(without dereferencing it) is not possible, but this is irrelevant,

No, it isn't.

since as a debugger writer I am free to use whatever machine
dependencies

Yes, you are, but in *this* newsgroup we discuss machine-independent
code.

<snip>

There you go. Final argument in "how to write code and why" is "tools
you are talking about are off-topic here". Or was it about "how to
debug strictly conforming programs using only standard tools and
techniques"? Not that I get that "using junk pointers makes debugging
easier" concept, but either the whole discussion is off-topic here
(which it is, isn't it) or you got to admit the fact that people write
code in real life sometimes, using some non-standard tools (debugger!).

Well, there're literally millions of system dependencies and tools for
C programming. If they're all made topical here, focus (and expertise)
will be spread so thin as to be almost useless.

IMHO, NULL is better than an indeterminate value. In most situations
the assignment/s shouldn't take any significant time. As Richard Bos
pointed out, it may become tedious for large programs, but for small
to medium sized projects, it's one way to minimise scope for UB. It
helps in signalling mistakes, not in avoiding them.

[Yevgen Muntyan]

santosh wrote:

Yevgen Muntyan wrote:

>Richard Heathfield wrote:

>>Racaille said:

On Feb 14, 3:14 pm, Richard Heathfield <[e-mail]:
>Also, the value of the pointer may give someone who is debugging
>the program
>precious clue on where the value did come from
No, because inspecting the value is not allowed. The value is
indeterminate, and inspecting it invokes undefined behaviour.

<snip>

>>>I know there may be machines where just 'inspecting' a invalid pointer
(without dereferencing it) is not possible, but this is irrelevant,
No, it isn't.

since as a debugger writer I am free to use whatever machine
dependencies
Yes, you are, but in *this* newsgroup we discuss machine-independent
code.

<snip>

>There you go. Final argument in "how to write code and why" is "tools
you are talking about are off-topic here". Or was it about "how to
debug strictly conforming programs using only standard tools and
techniques"? Not that I get that "using junk pointers makes debugging
easier" concept, but either the whole discussion is off-topic here
(which it is, isn't it) or you got to admit the fact that people write
code in real life sometimes, using some non-standard tools (debugger!).

Well, there're literally millions of system dependencies and tools for
C programming. If they're all made topical here, focus (and expertise)
will be spread so thin as to be almost useless.

I didn't say those tools are topical. Point is that if one talks
about why some way to write code is "better", then he got to accept
that some people write code which plays well with some tools, or
code which in any implementation-defined ways is better than other
code. Or something. You know, like such thing:

char *a = malloc(10);
char *b = malloc(10);
/* which one to free first, a or b? */

"Fragmentation" is off-topic here, but it's not an argument
why one should call free() in the same order as malloc() was
called. Or vice versa.

The right way is somewhere in between The Right Way (which doesn't
exist anyway) and Works For Me. And one can't simply say the latter
is wrong because it's off-topic.

IMHO, NULL is better than an indeterminate value. In most situations
the assignment/s shouldn't take any significant time. As Richard Bos
pointed out, it may become tedious for large programs, but for small
to medium sized projects, it's one way to minimise scope for UB. It
helps in signalling mistakes, not in avoiding them.

IMHO, it depends and it doesn't make much sense to talk about
which is better at all. Same thing as goto and multiple returns
from a function (even though some people believe there is one correct
answer).

[Christopher Layne]

Yevgen Muntyan wrote:

IMHO, it depends and it doesn't make much sense to talk about
which is better at all. Same thing as goto and multiple returns
from a function (even though some people believe there is one correct
answer).

Here we go again with the "individual rights" preaching.

[santosh]

Yevgen Muntyan wrote:

santosh wrote:

Yevgen Muntyan wrote:

Richard Heathfield wrote:
Racaille said:

<snip>

>>since as a debugger writer I am free to use whatever machine
dependencies
Yes, you are, but in *this* newsgroup we discuss machine-independent
code.

<snip>

There you go. Final argument in "how to write code and why" is "tools
you are talking about are off-topic here". Or was it about "how to
debug strictly conforming programs using only standard tools and
techniques"? Not that I get that "using junk pointers makes debugging
easier" concept, but either the whole discussion is off-topic here
(which it is, isn't it) or you got to admit the fact that people write
code in real life sometimes, using some non-standard tools (debugger!).

Well, there're literally millions of system dependencies and tools for
C programming. If they're all made topical here, focus (and expertise)
will be spread so thin as to be almost useless.

I didn't say those tools are topical. Point is that if one talks
about why some way to write code is "better", then he got to accept
that some people write code which plays well with some tools, or
code which in any implementation-defined ways is better than other
code. Or something. You know, like such thing:

Yes, that's why discussions on best practises in programming have been
so heated. Code that's optimised to work with certain other code is
perfectly fine. In fact, many popular pieces of software are precisely
built this way. But discussion of such code would be best taken to a
more specific group.

<snip>

IMHO, NULL is better than an indeterminate value. In most situations
the assignment/s shouldn't take any significant time. As Richard Bos
pointed out, it may become tedious for large programs, but for small
to medium sized projects, it's one way to minimise scope for UB. It
helps in signalling mistakes, not in avoiding them.

IMHO, it depends and it doesn't make much sense to talk about
which is better at all. Same thing as goto and multiple returns
from a function (even though some people believe there is one correct
answer).

You've expressed your HO and I've expressed my HO. We're at a
stalemate. What about calling quits on this discussion? It's a minor
issue and it's dragged on far enough.

[Chris Dollin]

Yevgen Muntyan wrote:

IMHO, it depends and it doesn't make much sense to talk about
which is better at all. Same thing as goto and multiple returns
from a function (even though some people believe there is one correct
answer).

It makes sense to talk about which is "better" if the result is
to expose the ways in which it is better (or worse) and how those
play into whatever context one might have.

(This applies generally; it's not restricted to the Clear Pointer
debate.)

Eventually one has to make a judgement about what one will do in
one's code. Discussions of the trade-offs inform that judgement.

[The thing wrong with multiple returns from a function is the same
thing that's wrong with a single return from a function: it may
make it harder to see what's going on and to change it if one
has to. Clarity trumps rules.]

--
Chris "electric hedgehog" Dollin
"We did not have time to find out everything we wanted to know."
- James Blish, /A Clash of Cymbals/

[Arthur J. O'Dwyer]

On Wed, 14 Feb 2007, Christopher Layne wrote:

Racaille wrote:

>>
Setting it to NULL when not needed is a spurious state change, so it's
noise and it makes debugging harder.

No, it's an explicit state change. Which means when it is used, you know
exactly where to find THE ERROR. What is difficult for you to understand
about this non-obtuse approach?

Well, I personally am ambivalent about post-free NULL-setting. I don't
do it myself, for reasons I'm about to describe; but I understand why
some people do do it, for the reasons you've been stating.

(1) Nothing is a panacea. "THE ERROR" is usually two lines above the
segfault, in which case it's easy to spot, whether you assign NULL or
not; but often it's in a branch of the call graph that's no longer
even on the stack, or maybe not even in the same thread! Now, assigning
NULL to dead pointers can make debugging-with-a-debugger easier, sure,
but it's not a panacea. (This is more a response to your hyperbole
above than a reason not to assign NULL. But if it /were/ really a
cure-all, I'd hardly be able to object to it, would I?)

(2) Assigning NULL to dead pointers takes screen real estate. It also
can take up RAM real estate, on embedded platforms where the size of
the executable is critical. (Unless, of course, you use a smart compiler
that optimizes away the useless writes, in which case you're back where
you started, with less debuggability and more source code --- the
worst of both worlds.)

(3) Dead writes in general screw up static analysis tools (like 'lint',
to take a terrible example). Either you'll get a lot of false positives
("Variable 'p' written on line 42, but never read"), or else you'll
turn off that warning and miss a lot of true positives.

Static analysis is the reason I /do/ take a firm stand against
the practice of initializing all variables at their definitions, which
is essentially the flip side of re-assigning all pointers after their
last use. If you do that, you're deliberately crippling static analysis
by removing all the "Variable 'p' used without being initialized"
warnings. Computers are better at control-flow analysis than humans
are; let them do their jobs!

-Arthur

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

Racaille said:

[...]

>Also, the value of the pointer may give someone who is debugging
the program precious clue on where the value did come from

No, because inspecting the value is not allowed. The value is
indeterminate, and inspecting it invokes undefined behaviour.

[...]

The process of debugging isn't necessarily limited to what's defined
by the C standard. If I'm having a problem with a pointer, I won't
hesitate to take a look at its current value to diagnose the problem,
even if doing so invokes undefined behavior.

But if I look at it by adding, say, a printf call to my program, I'll
make sure that call temporary and doesn't appear in production code.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

Racaille wrote:

Richard Heathfield <[e-mail]:

.... snip ...

>>
No, because inspecting the value is not allowed. The value is
indeterminate, and inspecting it invokes undefined behaviour.

>>- by setting it to NULL, you have made it indeterminate.

No, by setting it to NULL, you have made it determinate!

Please, let's stop this, it gets ridiculous. You still feign not
to get my point. If you set it to NULL after very free(), then it
could be just any pointer ever passed to free(), and so it is
indeterminate from the point of view of somebody trying to trace it.

No, you are being ridiculous. This newsgroup deals with standard
C, not your hypothetical machine with various unknown extraneous
definitions. If you want to discuss non-standard things go to a
new group where it is topical, such as a group dealing with your
system.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[CBFalconer]

Richard Heathfield wrote:

Chris Dollin said:

.... snip ...

>

>>It might not only be goats that use trollguns, and anyway there may
be other circumstances where you need to destroy a trollgun other
than the one where you are destroying - sorry! deleting - a goat.

Yes - but the same argument applies: either I'm going to destroy
the place that pointed to the gun, so no point nulling it, or I'm
going to give it a new value, so no point nulling it.

No, there's another possibility - that the entity that had the gun no
longer has a gun (I dunno, perhaps the troll rips out the arm that was
holding it or something), and thus NULL is an appropriate value for
that pointer. For me, this is often the case, (not that I use trollguns
very often) - objects gain and lose other objects with careful abandon.

I thought the UK had some fairly strict gun control laws. You
can't just allow any old goat to roam about shooting random
trolls. Some have redeeming values.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Ian Collins]

Racaille wrote:

On Feb 14, 5:35 am, Ian Collins <[e-mail]:

>>If a pointer is null, you can free it as often as you like. Try to
dereference it and you'll soon know what's wrong. Dereferencing or
freeing an invalid pointer has undefined and indeterminate results.

No, if you free a pointer multiple times, than the logic of your
program
is broken at its core, and you should probably rewrite the thing from
scratch.

You miss my point which was attempting to dereference a freed pointer is
a more insidious bug than attempting to free it twice.

People have put things in place to help you deal with that before the
things get bigger - for instance, free() may issue a diagnostic if
passed
an already freed pointer.

Or the developer my chose to add a wrapper that checks for null.

I'm not offering advice, just an opinion.

--
Ian Collins.

[santosh]

ra************@yahoo.co.in wrote:

On Feb 14, 4:00 pm, Richard Heathfield <[e-mail]:

[e-mail] said:

<snip>

we are discussing how to avoid of breaking C Rules ( or better what
may be outcome of accessing freed memory) and to explain this i need
to break the rules.(Correct me if i done wrong. or better example.)

You're wrong. Breaking the rules teaches you nothing about the language,
because by breaking the rules you are giving the implementation the
freedom to provide any behaviour whatsoever, or even no behaviour
whatsoever if it prefers.

i agree on most of your suggestion

may you have example that show the things and Don't Break rule for
what may be the behaviour of accessing memory after freeing even if
one SHOULD NOT access it. ?

Code that attempts to access free()'ed memory cannot be portable. It's
recklessly dangerous and totally unneccessary.

<snip>

[Beej]

Whoa, there, gents. Next time I'll put a ;) next to the code, too.

-Beej

[Richard Heathfield]

Keith Thompson said:

Richard Heathfield <rj*@see.sig.invalidwrites:

>Racaille said:

[...]

>>Also, the value of the pointer may give someone who is debugging
the program precious clue on where the value did come from

No, because inspecting the value is not allowed. The value is
indeterminate, and inspecting it invokes undefined behaviour.

[...]

The process of debugging isn't necessarily limited to what's defined
by the C standard.

The bits of it that are topical here, however, are.

If I'm having a problem with a pointer, I won't
hesitate to take a look at its current value to diagnose the problem,
even if doing so invokes undefined behavior.

....and I won't hesitate to use a (carefully abstracted) extension if I
cannot get the required functionality in a more portable way. That
doesn't mean extensions are topical here.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Heathfield]

Beej said:

Whoa, there, gents.

Worry not - Chris and I are just shooting the breeze, really. If it
sounds heated, you're misreading it. (And Chris owes me a pint - I'm
certain of it.)

Next time I'll put a ;) next to the code, too.

And spoil our fun?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

Keith Thompson said:

>Richard Heathfield <rj*@see.sig.invalidwrites:

>>Racaille said:

[...]

>>>Also, the value of the pointer may give someone who is debugging
the program precious clue on where the value did come from

No, because inspecting the value is not allowed. The value is
indeterminate, and inspecting it invokes undefined behaviour.

[...]

The process of debugging isn't necessarily limited to what's defined
by the C standard.

The bits of it that are topical here, however, are.

I agree, of course -- but your statement above *could* be interpreted
to imply that non-standard stuff doesn't exist, not just that it's
off-topic. Racaille's statement that "the value of the pointer *may*
give someone who is debugging the program precious clue" is quite
correct. The detailed reasons why it's correct on a particular
platform are off-topic; the fact that it's correct (and that an
implementation *may* allow examination of an indeterminate pointer
value) is topical.

[...]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Keith Thompson said:

[...] but your statement above *could* be interpreted
to imply that non-standard stuff doesn't exist, not just that it's
off-topic.

Yes, perhaps it could be interpreted that way if one struggled long and
hard enough to do so, but only a very recent newcomer to the group who
had done no research whatsoever could possibly believe that I intended
that interpretation. I have said many times in this group that there is
nothing wrong with discussing implementation-specific stuff *in its
place* - which isn't here.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Bos]

Christopher Benson-Manica <at***@otaku.freeshell.orgwrote:

Ian Collins <ia******@hotmail.comwrote:

Richard Bos wrote:

The problem with that is "attempting". You will, sooner or later, fail
in your attempt. And then, because you believe that all your pointers
are either null or valid, you will not be able to find the bug until

Can you cite an example where setting a pointer to NULL could mask a
bug? The way I see it is there are three things you can do with a
pointer, test it, dereference it and free it. Once set to NULL, the
first to will fail and the third is harmless.

You missed Richard's point. The problem lies not in setting the
pointer to NULL, but in *believing* one has when in fact one has not.

Quite. To be precise, the problem lies in having more than one copy of
the same pointer, and then only setting one of them - the one that was
explicitly passed to free() - to null. The other copies are now just as
invalid (indeed, more so) than the nulled one, but since they're not
null your magic wand won't detect this.
(The problem also lies in ordinary human failure, which is easier to
detect if one assumes that one might have made one than if one assumes
one has patched all holes by setting pointers to null.)

Richard

[Chris Dollin]

Richard Heathfield wrote:

Beej said:

>Whoa, there, gents.

Worry not - Chris and I are just shooting the breeze, really.

Exemplifying constructive disagreement [1], right?

If it sounds heated, you're misreading it.

Concur.

(And Chris owes me a pint - I'm certain of it.)

We should perhaps arrange another meetlet, and constructively
disagree about who owes who pints.

[1] It's easier to swallow dictionaries if you grind them first.

--
Chris "electric hedgehog" Dollin
"How am I to understand if you won't teach me?" - Trippa, /Falling/

[Richard Heathfield]

Richard Bos said:

<snip>

To be precise, the problem lies in having more than one copy of
the same pointer, and then only setting one of them - the one that was
explicitly passed to free() - to null. The other copies are now just
as invalid (indeed, more so) than the nulled one, but since they're
not null your magic wand won't detect this.

Strawman. Nobody is claiming that giving a pointer a null value is a
magic wand. It's merely a way to reduce the likelihood of your program
exhibiting undefined behaviour.

(The problem also lies in ordinary human failure, which is easier to
detect if one assumes that one might have made one than if one assumes
one has patched all holes by setting pointers to null.)

Better still is to take every reasonable opportunity to make sure that
your program doesn't exhibit undefined behaviour. If you have multiple
pointers to an object that is about to cease to exist, then it makes
sense to sort these references out *before* freeing the object. If it
makes sense for these pointer values to continue to refer to that
object, then it doesn't make sense to destroy the object. So clean up
first, and *then* delete the object. Common sense, surely?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[CBFalconer]

Chris Dollin wrote:

Richard Heathfield wrote:

.... snip ...

>

>(And Chris owes me a pint - I'm certain of it.)

We should perhaps arrange another meetlet, and constructively
disagree about who owes who pints.

We can tentatively assume Richard owes. This resolves the first
round. After each round simply assume the previous assumption was
wrong, and do the right thing. You may need to ensure wives are
available and willing to extricate the end result.

Maybe this algorithm belongs on comp.programming?

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Richard Bos]

CBFalconer <cb********@yahoo.comwrote:

Chris Dollin wrote:

Richard Heathfield wrote:

(And Chris owes me a pint - I'm certain of it.)

We should perhaps arrange another meetlet, and constructively
disagree about who owes who pints.

We can tentatively assume Richard owes. This resolves the first
round. After each round simply assume the previous assumption was
wrong, and do the right thing. You may need to ensure wives are
available and willing to extricate the end result.

Maybe this algorithm belongs on comp.programming?

We need a comp.programmer.recovery. And a decent pub. Princess Louise?

Richard