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

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.

>-Don't worry - all is not lost.  No one was able to come up with a real
>-world example of something like this. 

>Nobody came up with YOUR example, but there were several examples
>posted of genuine computer architectures where continued access of
>an invalid pointer value would cause problems.

I won't rehash this since this whole pointer thing was a topic off the
longest thread I have ever seen in comp.lang.c.  Unless I missed
a posting on the other thread, *no one* was able to provide a specific
example and an architecture *and* an associated C implementation on
*that* architecture that created such a problem for C programs.  In
other words, the code generated by the C compiler did not tempt
Murphy's Law even though the architecture had the potential.

If someone out there knows of such an implementation please share it
with us.  I am interested in seeing the assembly code output of
a C routine the bombs by *assigning* or *comparing* bad pointer.


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