free()

[Chris Dollin]

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.]

 

[CBFalconer]

.... snip ...

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]

Chris Dollin said:
.... snip ...


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

 

[Arthur J. O'Dwyer]

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]

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.

 

[Ian Collins]

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.

 

[santosh]

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:

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]

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?

 

[Keith Thompson]

Keith Thompson said:

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.

[...]

 

[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 Bos]

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]

Beej said:


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.

 

[Richard Heathfield]

Richard Bos said:

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?

 

[CBFalconer]

Richard Heathfield wrote:
.... snip ...


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]

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