phd_ivo@gsbacd.uchicago.edu (02/24/89)
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. 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. ivo welch phd_ivo@gsbacd.uchicago.edu
pratt@boulder.Colorado.EDU (Jonathan Pratt) (02/25/89)
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. ... > This would be extremely trivial to do... It's an interesting idea, but not exactly trivial to implement. Defining legal writing areas would be pretty complicated. You'd probably have to do something like TMON's heap check at every write. This might be too slow even for debugging purposes. Jonathan /* Jonathan Pratt Internet: pratt@boulder.colorado.edu * * Campus Box 525 uucp: ..!{ncar|nbires}!boulder!pratt * * University of Colorado * * Boulder, CO 80309 Phone: (303) 492-4293 */
phd_ivo@gsbacd.uchicago.edu (02/25/89)
>legal writing areas would be pretty complicated. You'd probably have >to do something like TMON's heap check at every write. This might be >too slow even for debugging purposes. > >Jonathan > >/* Jonathan Pratt Internet: pratt@boulder.colorado.edu * True, getting it perfect may not be so trivial. But at least one could check if the immediate pointer write goes into the program's code segment, or into some other program's segment. As legal writing areas, one would want to exempt also video RAM and NuBus RAM, as well. If you mess up your program's own heap, does the Mac OS blow up? I have never become so proficient in the Mac World to know this. I think at least the simple version would go a long way towards easier development in non-PMMU-protected environments.
siegel@endor.harvard.edu (Rich Siegel) (02/25/89)
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
alexis@ccnysci.UUCP (Alexis Rosen) (02/26/89)
In article <1993@tank.uchicago.edu> phd_ivo@gsbacd.uchicago.edu writes: >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. Unfortunately, this would also make the environment useless for a large number of people. How do you carry around references to functions or procedures? And what if I want to call traps directly (bad practice, but some people use it for speed in time-critical routines)? There is also no way to assure that your code doesn't go wild in lots of other ways, and _then_ trash everything. The problem is that this method would be good for code which doesn't deal much with Mac System stuff. On the other hand, that is the kind ot code that least needs protection. Figuring out what is legal and what is not is most difficult (perhaps undecideable) in precisely those cases where it would be most useful. I think that we must wait for the '851 (or '30), and for software to make it go. Alexis Rosen alexis@ccnysci.uucp