Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!unmvax!bbx!bbxsda!scott
From: scott@bbxsda.UUCP (Scott Amspoker)
Newsgroups: comp.std.c
Subject: Re: Out-of-bounds pointers
Message-ID: <238@bbxsda.UUCP>
Date: 10 Oct 89 22:15:34 GMT
References: <1009@mtxinu.UUCP> <12570028@hpclwjm.HP.COM> <868@crdos1.crd.ge.COM> <217@bbxsda.UUCP> <11234@smoke.BRL.MIL> <231@bbxsda.UUCP> <4813@tekcrl.LABS.TEK.COM>
Reply-To: scott@bbxsda.UUCP (Scott Amspoker)
Organization: Basis International,  Albuquerque, NM
Lines: 32

In article <4813@tekcrl.LABS.TEK.COM> terryl@tekcrl.LABS.TEK.COM writes:
 +
 +As my original posting explained, the pointer *is* manipulated by
 +popping it off the stack upon return from free().  The original
 +posting explained every step that takes place leading up to the core
 +dump.  If you believe that any of those steps violates the ANSI draft
 +then please state which one.
 
      Um, err, how about the one that says C arguments are "call by value,
>and not by reference". If I remember correctly, your initial argument said
>that p could live in a special address register, then placed on the stack
>for the call to free(), and then popped off of the stack and put back in
>that special address register; that's call by value/result, not call by
>value, so the last step (put back in that special address register) should
>NOT be done at all.....

It is customary for subroutines (such as free()) to save registers
on the stack and restore their values upon return.  NOTHING IS
BEING PASSED BACK TO THE CALLER!  The subroutine is merely
restoring a register to its original value.  The value of the
pointer is being pushed as an argument to the subroutine.  That
value ultimately is discarded.  However, the register containing
the pointer may also be pushed to preserve its value.  Please check
some assembly code output of practically any C compiler of a function 
that uses register variables.


-- 
Scott Amspoker
Basis International, Albuquerque, NM
(505) 345-5232
unmvax.cs.unm.edu!bbx!bbxsda!scott