Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!husc6!endor!siegel
From: siegel@endor.harvard.edu (Rich Siegel)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Suggestion for the LSC compiler writers
Message-ID: <1273@husc6.harvard.edu>
Date: 24 Feb 89 21:25:13 GMT
References: <1993@tank.uchicago.edu>
Sender: news@husc6.harvard.edu
Reply-To: siegel@endor.UUCP (Rich Siegel)
Organization: Symantec/THINK Technologies, Bedford, MA
Lines: 53

In article <1993@tank.uchicago.edu> phd_ivo@gsbacd.uchicago.edu writes:
>
>The reason I don't use LSC or any other micro compiler is that there is
>a lack of protection against my out-of-range pointers overwriting some
>other storage space. 

	The reason there's no such protection on the Macintosh is because
there's no differentiation between code and data space, and it is useful
(on the Mac in particular) to be able to write to strange locations (a
low-memory global, for example, or to store a value in a PC-relative
address).

>It would be trivial for a compiler to include an optional
>"anti-efficiency" switch so that each time the compiler creates an
>assignment (e.g.  to a pointer), the compiler inserts code that checks
>if this location is outside the data segment.  If there is, a warning or
>abort routine could be called.  This would be extremely trivial to do
>for the compiler implementer, and would go very far in making the
>development process much less painful. 

	It's anything but trivial. Let's say you have an address. If this
hypothetical checking were implemented, it would have to check

	1) Whether the address points to some reasonable stack-relative
	position, so that it doesn't smash, say, the return addresses of
	ANY active procedures in the call chain.

	2) Whether the address is in a valid range below A5, so that it
	can't smash anything important, like the jump table.

	3) Whether the address is not going to hit any important 
	system globals, like the exception vectors or Macintosh system
	globals.

	4) Whether the address lies in a valid block in ANY heap currently
	in the system.

I may have missed some instances, but you get my point. The suggestion is not
an unreasonable one (and I will pass it on), but it is not easy to implement,
nor is it (in my opinion) worthwhile, especially when there are things like
TMON's trap discipline, heap checking, and checksum, not to mention some
good old-fashioned debugging techniques.

		--Rich



Rich Siegel
Staff Software Developer
THINK Technologies Division, Symantec Corp.
Internet: siegel@endor.harvard.edu
UUCP: ..harvard!endor!siegel
Phone: (617) 275-4800 x305