) (01/19/89)
Background: Tim Maroney (tim@hoptoad.uucp) was bit by a handle dereferencing problem, roughly (*h)->p = NewPtr(size) expanded by the compiler as pointer = *h; temp = NewPtr(something); pointer->p = temp; However, as a side-effect of NewPtr, the value of *h changed AFTER the compiler had computed the value it will use. In a recent note, Tim mentioned that the problem wasn't well-documented and several correspondants pointed to references in Inside Mac to the Pascal compiler's actions. I would hold with Tim: the problem is subtle, and one that practically every beginning C programmer discovers the hard way, myself included (and I don't even have the excuse of being a beginner). As I see it, the main problem is not that the programmers are wrong, but that that programming the Mac is poorly documented. (This is not a question of the "what" of Inside Mac, but the "why" that builds on Inside Mac.) Several contributors to comp.sys.mac.programmer help ease the problem (Rich Siegal at Think, Larry Rosenstein and many others at Apple), but the real issue is that the competent programmer moving to the Mac is faced with a huge body of unstructured information with no good aids to navigation, other than the MacTutor collections. I dunno, maybe I should write that book... Martin Minow minow%thundr.dec@decwrl.dec.com
earleh@eleazar.dartmouth.edu (Earle R. Horton) (01/19/89)
In article <8901181811.AA20048@decwrl.dec.com> minow@thundr.dec.com (Repent! Godot is coming soon! Repent!) writes: >Background: Tim Maroney (tim@hoptoad.uucp) was bit by a handle dereferencing >problem, roughly > (*h)->p = NewPtr(size) >expanded by the compiler as > pointer = *h; > temp = NewPtr(something); > pointer->p = temp; >However, as a side-effect of NewPtr, the value of *h changed AFTER the >compiler had computed the value it will use. > >In a recent note, Tim mentioned that the problem wasn't well-documented >and several correspondants pointed to references in Inside Mac to >the Pascal compiler's actions. > >I would hold with Tim: the problem is subtle, and one that practically >every beginning C programmer discovers the hard way, myself included >(and I don't even have the excuse of being a beginner). > Unless that programmer is paranoid, like myself. I learned to program in C on the Mac. I read K&R first, cover to cover. I read the Memory Manager chapter of IM, and saw the warnings about how certain calls could cause relocatable blocks to be moved. I saw from K&R that one cannot predict the order in which parts of an expression or statement will be evaluated. Using the knowledge that blocks could be moved, and that a C compiler will generate many more lines of assembler code than it gets as C source code, I, a mere beginner, concluded that the only safe way to use non-relocatable blocks was this: ******************************************************************** * Never reference the contents of a relocatable block on the * * same line of source code as any ToolBox or Operating System call.* ******************************************************************** Overly cautious, perhaps, but I still adhere to this policy after three years of Macintosh programming, the bulk of it in C, and I have not been bitten by this problem. >... but the real >issue is that the competent programmer moving to the Mac is faced >with a huge body of unstructured information with no good aids to >navigation, other than the MacTutor collections. > The real issue is that certain parts of the Macintosh operating system operate according to fundamentally different principles than do corresponding parts of other operating systems. The Memory Manager is a perfect example. An experienced programmer will read the existing Macintosh documentation, and will assume that what he is reading means the same thing as something he has read before, in a UNIX man page for example. As a result, he will tend to not see things in the documentation that jump right out at a beginner. Future operating systems may well incorporate principles that are even "stranger" than relocatable blocks of memory, and that might perhaps be even harder for experienced programmers to understand than the Macintosh. The only solution is to be careful. Earle R. Horton. 23 Fletcher Circle, Hanover, NH 03755--Graduate student. He who puts his hand to the plow and looks back is not fit for the kingdom of winners. In any case, 'BACK' doesn't work.