🚀 go-pugleaf

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.....