Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!ncis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!thundr.dec.com!minow
From: minow@thundr.dec.com (Repent! Godot is coming soon! Repent!)
Newsgroups: comp.sys.mac.programmer
Subject: Unexpected handle dereferencing revisited
Message-ID: <8901181811.AA20048@decwrl.dec.com>
Date: 18 Jan 89 18:08:00 GMT
Organization: Digital Equipment Corporation
Lines: 32

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