pointer poison (was: effect of free())

Scott Amspoker scott at bbxsda.UUCP
Fri Sep 29 03:33:55 AEST 1989


In article <1989Sep28.101227.9645 at twwells.com> bill at twwells.com (T. William Wells) writes:
>I doubt it. The problem is probably with the long References: line.

Wow, it worked.  That thread was getting awfully long.

>I'm not sure what you are talking about. The original posting in this
>thread (mine) said that the C standard permits the compiler writer to
>assume that you don't use a pointer after a free...
>[...]
>If I write the program so that it is not designed to reference
>pointers after they are freed, assuming I get it right, it doesn't
>matter whether the generated code trashes the pointer...
>[...]
>The conclusion is that I should avoid referencing the pointer after
>it is freed, so that this perfectly legit optimization won't break my
>code.

I agree, the original posting had to do with testing a pointer after
a free() call.  However, the discussion quickly expanded into pointer
handling in general.  Many readers were concerned that their code
could possibly be testing or moving a pointer that did not contain
a valid address.  Even though their programs may have the appropriate
logic in place that would prevent ultimate *dereferencing* of such a
pointer, it was suggested that merely handling such a pointer is
considered a bug: (ex:  p1 = p2  causes a trap if p2 contains an
invalid address).  While I would agree that handling a pointer
that you won't ultimately be using (because of some later 
condition) is questionable style - it's hardly an outright *bug*.

Since nobody was able to provide a real life example of such a
trap taking place under those conditions, none of us can be
*100%* certain that any non-trivial program does not contain such
a violation (since it would go unpunished).  (Which also means
that the whole issue is moot).

With the bazillion different things we have to worry about to
write truely protable code we don't need yet another grey zone
to deal with so that some future hardware designer can trim
few microseconds off of programs.

-- 
Scott Amspoker
Basis International, Albuquerque, NM
(505) 345-5232



More information about the Comp.lang.c mailing list