Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!eecae!cps3xx!rang From: rang@cpsin3.cps.msu.edu (Anton Rang) Newsgroups: comp.sys.mac.programmer Subject: Re: serious code generation bug in Lightspeed C Message-ID: <1532@cps3xx.UUCP> Date: 15 Jan 89 17:50:27 GMT References: <6275@hoptoad.uucp> <1676@helios.ee.lbl.gov> <6315@hoptoad.uucp> Sender: usenet@cps3xx.UUCP Reply-To: rang@cpswh.cps.msu.edu (Anton Rang) Organization: Michigan State University, Computer Science Dept. Lines: 33 In-reply-to: tim@hoptoad.uucp's message of 15 Jan 89 12:18:10 GMT In article <6315@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > It is silly to say that this is a well documented problem. I've read > three drafts of Inside Mac, starting with the loose-leaf binder edition > unfathomable aeons ago, and that an assignment could require locking > has never been explicitly mentioned. Well, maybe not *well* documented, but documented at least. From Inside Mac, volume II, page 16: The Lisa Pascal compiler frequently dereferences handles during its normal operation. You should take care to write code that will protect you when the compiler dereferences handles in the following cases: [ ... ] Assigning the result of a function that can move or purge blocks (or of any function in a package or another segment) to a field in a record referred to by a handle, such as aHandle^^.field := NewHandle(...) A problem may arise because the compiler generates code that dereferences the handle before calling NewHandle--and NewHandle may move the block containing the field. Maybe this should have been emphasized more, but it was at least mentioned (otherwise I probably would have run into it before). +---------------------------+------------------------+----------------------+ | Anton Rang (grad student) | "UNIX: Just Say No!" | "Do worry...be SAD!" | | Michigan State University | rang@cpswh.cps.msu.edu | | +---------------------------+------------------------+----------------------+