Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!rpi!pawl!shadow From: shadow@pawl.rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: Catching free memory violations Message-ID: Date: 5 Aug 89 21:32:40 GMT References: <681@lpami.wimsey.bc.ca> <7426@ecsvax.UUCP> Sender: usenet@rpi.edu Organization: Rensselaer Polytechnic Institute, Troy, NY Lines: 31 In-reply-to: utoddl@ecsvax.UUCP's message of 3 Aug 89 14:34:48 GMT In article , shadow@pawl.rpi.edu (Deven T. Corzine) writes: Deven> Ah, but interrupts are forbidden to call the memory allocatio Deven> routines, as the system free memory list may well be corrupt. Deven> So, people expect Forbid()/Permit() to work... On 3 Aug 89 14:34:48 GMT, utoddl@ecsvax.UUCP (Todd M. Lewis) said: Todd> People also expect FreeMem() to return the memory to the system. Todd> FreeMem() can be expected to change the contents of the freed Todd> ram (for example, to link it into the free memory list). Think Todd> of it as Todd> #define TrashThisRAM FreeMem Todd> and you'll begin to get my point. I understand your point completely. My point is that people have used recently freed memory while forbidden, and know it to currently work. They' can't reasonably *expect* it to work, but to break it unnecessarily isn't of value either. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.