Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!portal!cup.portal.com!Tim_CDC_Roberts
From: Tim_CDC_Roberts@cup.portal.com
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <21952@cup.portal.com>
Date: 7 Sep 89 16:37:32 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU>
  <1989Aug17.005548.745@twwells.com> <16022@vail.ICO.ISC.COM>
  <248@seti.inria.fr> <246@ssp1.idca.tds.philips.nl>
Organization: The Portal System (TM)
Lines: 47

From Dolf Grunbauer, Martin Jourdan, Dick Dunn and T. William Wells:
 
>>>> ...For example, the following code fragment is nonportable:
>>>>    char    *ptr;
>>>>    ptr = malloc(1);
>>>>    free(ptr);
>>>>    if (ptr == 0) ...
>>>> The if might cause a trap when the value of ptr is accessed.
>>>Not true.  The "if" only examines the value of the pointer, not what it
>>>points to.
>>You're wrong, Dick.  Someone else already pointed it out, but let me
>>make it clear again.  Imagine a segmented memory architecture with
>>protections, and imagine that the call to "free" above frees the last
>>used block in the segment and that "free" is clever enough to
>>determine it and decides to release the segment to the OS, thus making
>>the whole segment invalid [...]
>> [...].  Then merely loading the value of "ptr" in a register to test it
>>against 0 will cause a invalid-address trap.
>
> I agree with Dick, as the original statement is:
>    if (ptr == 0) ...
> I think Martin explained why the statement:
>    if (*ptr == 0) ...
> is unacceptable and how the OS could trigger this illegal use.
> Is this true or am I missing Martin's point ?
 
I know I'm going to be sorry for entering into this.
 
Isn't this a quality of implementation issue?  In any architecture where
simply placing a value into an address register causes a hardware
validation of that address (CDC Cyber 170, for example), there MUST be an
alternative method of manipulating arbitrary bit patterns without
restriction.  That is, it MUST be possible to load the value of an
invalid address (which some of the "arbitrary bit patterns" would be)
into a general-purpose register.  Thus, in the case above, I would
insist that the compiler writer move the address to a general-purpose
register and do the comparison there.  Any other behaviour I would document
as a bug.
 
In the CDC Cyber 180s, which use a segmented memory architecture very
similar to the one described in the test case, any bit pattern may be
loaded and manipulated in an address register; address, segment and
ring validation is not done until an attempt is made to deference the
value.

Tim_CDC_Roberts@cup.portal.com                | Control Data...
...!sun!portal!cup.portal.com!tim_cdc_roberts |   ...or it will control you.