effect of free()

[Doug Gwyn]

In article <871 at cirrusl.UUCP> dhesi%cirrusl at oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
>So how portable is a C program that examines a freed pointer without
>dereferencing it?  Probably not 100.000% portable, but close enough
>that it makes little difference.

People who have implementations like that wouldn't agree with you.

>Then, if
>you have any time left, you can relax over lunch and dwell on largely
>theoretical endeavors...such as wondering if examining a freed pointer
>will give you a C program that might not run on *every* possible
>computer system that might exist in the entire world for the next
>century.

This is NOT an ivory-tower issue.  I certainly wouldn't be wasting
effort trying to explain it to you guys if it were.

I personally believe that architectures for which this is a real issue
SHOULD be designed, not just for dead-pointer access trapping, but in
order to obtain other benefits of tagged architectures.  The more code
there is that will fail miserably on a reasonable tagged architecture,
the more excuse there is for computer companies to not produce such
architectures.  Not too long ago I had a design engineer at one such
company inform me that the opportunity to produce a bit-addressable
architecture (which would be immensely helpful for many applications)
was being lost due to the Catch-22 argument that existing code would
not be able to use the bit-addressability feature.

Thus, arguing that computer should continue to look just like the
crufty pieces of junk you're currently used to can be to the long-term
detriment of the computing industry.  There is room for numerous
architectural improvements, and to the extent that they can be
anticipated and accommodated in programming language specifications,
the better off we all will be.