Path: utzoo!attcan!uunet!cbmvax!steveb
From: steveb@cbmvax.UUCP (Steve Beats)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Unsupported Programming Practices
Message-ID: <5632@cbmvax.UUCP>
Date: 5 Jan 89 19:22:11 GMT
References: <5605@cbmvax.UUCP> <10227@well.UUCP>
Reply-To: steveb@cbmvax.UUCP (Steve Beats)
Organization: Commodore Technology, West Chester, PA
Lines: 31

In article <10227@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>In article <5605@cbmvax.UUCP> carolyn@cbmvax.UUCP (Carolyn Scheppner CATS) writes:
>>                              IMPORTANT !    
>>       Official Warning to Rom-Jumpers, Structure-Hackers, and Others
>>       ==============================================================
>>Do not execute code on your stack or put system structures on your stack.
>
>	Why not?
>
>	I occasionally put RastPorts on my stack; does that count?
>
Yes that certainly does count.  If Exec ever gets its act together and starts
using the MMU, your stack would be private memory.  If graphics attempted to
access the RastPort (as a separate task through Intuition for instance) it 
would cause an illegal access exception.  I would suggest you either:-

a)	Allocate rastports using MEMF_PUBLIC
b)	Allocate a new stack using MEMF_PUBLIC

I'd like to point out that MEMF_PUBLIC is not really a solution but it should
help out in these retrograde cases.  The most likely solution is that we'll
introduce a new task type that knows it's running under MMU protection.  If
this is the case then your current practices are safe.  However, if this turns
out to be an impractical solution, at least we haven't killed all possibilities
by telling folks it's OK to stick stuff on the stack.

You can't put code on the stack because that's identical to writing self
modifying code.  Since the I-Cache doesn't do any bus snooping, it may have
already cached that location and won't notice the changed code.

	Steve