Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!wugate!uunet!zephyr.ens.tek.com!tekcrl!terryl
From: terryl@tekcrl.LABS.TEK.COM
Newsgroups: comp.std.c
Subject: Re: Out-of-bounds pointers
Message-ID: <4813@tekcrl.LABS.TEK.COM>
Date: 10 Oct 89 18:49:10 GMT
References: <1009@mtxinu.UUCP> <12570028@hpclwjm.HP.COM> <868@crdos1.crd.ge.COM> <217@bbxsda.UUCP> <11234@smoke.BRL.MIL> <231@bbxsda.UUCP>
Reply-To: terryl@tekcrl.LABS.TEK.COM
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 33

In article <231@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes:
+In article <11234@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
+ >In article <217@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes:
+ >-my_proc()
+ >-   {
+ >-   register char *p;
+ >-   p = (char*)malloc(1000);
+ >-   free(p);  /* free never returns but core dumps instead - why? */
+ >-   }
+ >-This seemingly innocent code could possibly error out according to the
+ >-"rules of comformance" presented by some readers.
+ >
+ >NO NO NO.  You have mispresented the argument.  So long as malloc()
+ >(assumed to be properly declared!) doesn't return a null pointer,
+ >the above will work in ALL conforming implementations.  The trouble
+ >arises only when after the free() the pointer p (NOT what it points
+ >to, that's inarguably invalid) continues to be examined or otherwise
+ >manipulated by the program.
+
+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.....