Path: utzoo!attcan!uunet!van-bc!
From: lphillips@lpami.wimsey.bc.ca (Larry Phillips)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Catching free memory violations
Message-ID: <681@lpami.wimsey.bc.ca>
Date: 30 Jul 89 22:15:49 GMT
Lines: 34
Return-Path: <lpami!lphillips>
To: van-bc!rnews

In <SHADOW.89Jul31154235@pawl.rpi.edu>, shadow@pawl.rpi.edu (Deven T. Corzine) writes:
>Robin> In article <3985@cps3xx.UUCP>, usenet@cps3xx.UUCP (Usenet file
>Robin> owner) writes:
>porkka> 		Forbid();
>porkka> 		FreeMem(x,len);
>porkka> 		playsomemore(x);
>porkka> 		Permit();
>
>porkka> Now if you go zeroing things out at the FreeMem call, you can
>porkka> potentially screw somebody up.
>
>Robin> FreeMem is just that. It gives the memory _back_ to the system
>Robin> which is then free to tag and use the memory anyway it wants
>Robin> to. Using free'd memory is a bad habit. Get rid of it. It does
>Robin> not work. Forbid() doesn't help.
>
>And yet, it IS assumed to be safe, if you're forbidden.  (It *may*
>even be (semi) officially sanctioned.  But I wouldn't count on it.)
>Regardless, people *expect* this to work, and it would help not to
>break it without needing to.

Why would anyone assume this was a safe thing to do? If you want to wrap a
Disable()/Enable() pair around that, I might be inclined to consider it
semi-safe.

-larry

--
"So what the hell are we going to do with a Sun?" - Darlene Phillips -
+-----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                 |
| \X/    lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322  -or-  76703.4322@compuserve.com        |
+-----------------------------------------------------------------------+