Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: The free() thing
Message-ID: <1989Sep16.221102.21919@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1989Sep14.022055.5961@twwells.com> <7513@bunker.UUCP>
Date: Sat, 16 Sep 89 22:11:02 GMT

In article <7513@bunker.UUCP> garys@bunker.UUCP (Gary M. Samuelson) writes:
>No compiler has any business changing the value of a variable
>I have declared, except when I have written code to do so.
>But even so, suppose there was another copy of that same pointer
>in another variable?  How will the compiler know about that one?

You have misunderstood completely.  The problem is not that the value of
the pointer variable might change.  The problem is that doing anything
with that value might cause a trap once it no longer points to valid
storage.  On many machines, pointers are just integer-like bit patterns
that you can diddle arbitrarily so long as you don't try to indirect
through them... but on *some* machines, they are heavily magical, the
hardware *knows* they point to something, and a pointer that no longer
points to anything valid is a dangerous object that might blow up in
your hands.  A maximally portable program must not mess with such
pointers.  This is a *fact*; the ANSI C standard just recognizes it.

>Notice to compiler vendors:
>No compiler I want to buy or use is going to exhibit this behavior.
>If I want to examine a pointer, I better be able to.

Your compiler vendors should have no problem satisfying this restriction
if you restrict your computer activities to the large-but-limited class of
well-behaved machines.  Some of us think this is a silly and unnecessary
restriction, especially for a supposedly-professional programmer.  In any
case, a language standard must avoid such restrictions as much as humanly
possible.
-- 
V7 /bin/mail source: 554 lines.|     Henry Spencer at U of Toronto Zoology
1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu