Path: utzoo!utgpu!watserv1!watmath!iuvax!purdue!haven!umd5!am524
From: am524@umd5.umd.edu (Matthew T. Russotto)
Newsgroups: comp.sys.mac.programmer
Subject: Re: StripAddress...
Message-ID: <6077@umd5.umd.edu>
Date: 2 Feb 90 03:34:35 GMT
References: <1990Feb2.010425.28126@oracle.com>
Reply-To: am524@umd5.umd.edu (Matthew T. Russotto)
Organization: University of Maryland, College Park
Lines: 47

In article <1990Feb2.010425.28126@oracle.com> gstein@oracle.uucp (Gregory Stein) writes:
+>[ I posted this once before and received no response, so I'm trying
+>  again... ]
+>
+>
+>    struct foo {
+>	int a, b, c;
+>    } **bar;
+>    bar = (struct foo **) NewHandle(sizeof(struct foo));
+>
+>Now, when I say "(*bar)->a" is this 32-bit clean?  For this example
+>and the current system software it is because the flag bits in the
+>handle represented by bar are zero, so there is no problem (the object
+>is not locked, purgable, or a resource).
Yes.  The problem with the flag bits being in the upper 8 bits of the master
pointer is NOT YOUR PROBLEM.  It is the MEMORY MANAGER itself which is NOT
32-bit clean (naturally, on 32-bit clean systems, the memory manager IS
32-bit clean, and the flags are stored elsewhere)

+>  What happens if I do something like:
+>
+>	HLock((Handle)bar);
+>	(*bar)->a = f();		/* f() and g() move memory */
+>	(*bar)->b = g();
+>	HUnlock((Handle)bar);
+>
+>Now, is this fragment still 32-bit clean? 
Yes.

+>Well, what should I do?  Calling StripAddress everywhere seems like a
+>job for Mr. Anal Retentive Programmer.  Should I ignore the issue when
+>dealing with handles?  i.e. if I get a handle with flag bits in the
+>master pointer, then I'm in 24-bit mode and I don't care, but if it
+>has no flag bits then I'm in 32-bit mode and I still don't care?  This
+>seems to be appropriate, but it also seems like the Mac can run in
+>32-bit mode but still use the current Memory Manager.  Or is 32-bit
+>mode only supposed to be turned on by, say, a NuBus driver who uses
+>lots of StripAddress calls and then turns 32-bit mode off?

You just summarized the right answer-- I can think of only two reasons
to call StripAddress-- one is when comparing master pointers, so you
don't get the flags (why you would want to compare master pointers is
a different question).  The other is when you have 32-bit mode on with
an UNCLEAN memory manager.  Then, it will strip Memory manager generated
pointers so your routine can still get at them (instead of wrapping into
bus-errorville).  Most programs will run with 24-bit mode always on.
On a 32-bit clean system, StripAddress returns its argument unchanged.