Path: utzoo!attcan!utgpu!watmath!watdragon!violet!afscian
From: afscian@violet.waterloo.edu (Anthony Scian)
Newsgroups: comp.std.c
Subject: Re: Out-of-bounds pointers
Message-ID: <17122@watdragon.waterloo.edu>
Date: 11 Oct 89 16:15:35 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> <238@bbxsda.UUCP>
Sender: daemon@watdragon.waterloo.edu
Reply-To: afscian@violet.waterloo.edu (Anthony Scian)
Organization: U. of Waterloo, Ontario
Lines: 41

In article <238@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes:
>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.
> 
>> [erroneous argument about call-by-reference]
>>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.
Being the author of the posting in question, let me say that the example
was supposed to show that it was possible to core dump even if the
"freed" pointer was never explicitly referenced or dereferenced.
Unfortunately, there is an important distinction between a
system-dependent "free" and a pANSI "free". The example for
OS/2 was specific to a low-level system "free" not pANSI "free".
A pANSI compliant compiler cannot allow this to happen with
the reserved library routine "free".

SUMMARY:
If the calling convention allows trapping pointer registers (on load
of bad value) to be saved across calls, it is up to the compiler
run-time library to allow the pointer passed to the pANSI routine
"free" to be LOADable in an address register after the "free" PERIOD.
Though POPable would be the minimum requirement in theory.

Anthony
//// Anthony Scian afscian@violet.uwaterloo.ca afscian@violet.waterloo.edu ////
"I can't believe the news today, I can't close my eyes and make it go away" -U2