[comp.sys.mac.programmer] More screwy AFP troubles

jverdega@cae.wisc.edu (Jeff Verdegan) (06/07/91)

Well, AppleTalk has done it again.  It's causing me to lose my mind!  Here's
the deal:

I'm using THINK C, version 4.0 (I just upgraded to 4.0.5, with the same results)
and I'm still on System 6.0.5.  After calling FPRead (via FPCommand, of course),
I want to look at what it is I've just read.  Not an unreasonable request, is
it?  Anyway, this comes back in xpb.XPP.XPP8.XPP7.XPP6.rbPtr, where xpb is
of type XPPParamBlock.  So there I am, double clicking my way down through the
structures/unions that make up this beast.  I get to ...rbPtr, set the type
to Address, double click to examine what it points to (something I've done
googols of times before), and WHAMMO! I get a "THINK C has unexpectedly quit"
alert, with an error code of 1 (bus error).  This also happens if I go in the
menu and change the type of ...rbPtr to Pascal string and (I would assume) C
string.  The address pointed to by ...rbPtr is even, so that shouldn`t be
the problem.  I've tried increasing memory for the debugger, for C, and for
my application, all to no avail.  I have looked at my pointers/handles, and
have found nothing that is unallocated, dangling, or otherwise naughty.  

Does anyone have an idea what might be causing this?  Is it obviously one of
my pointers/handles that I must just be missing?  Will Stephanie tell Brock 
that she's carrying the Emir's baby?  For the answers to these and other 
questions, tune in next time to c.s.m.p.

Thanks in advance! :)

Jeff Verdegan
jverdega@cae.wisc.edu

jverdega@serv1.uucp (Jeffrey Verdegan) (06/07/91)

Well, I figured out what the problem was (why I every time I tried to look at
...rbPtr, THINK C would exit and I'd have to reboot).  I had defined a macro
#define rbPtr(x) (x).XPP.XPP8.XPP7.XPP6.rbPtr to save me the trouble of typing
all that garbage in.  I also had a variable named rbPtr.  My guess is the macro
was being invoked by the variable, causing a nasty recursion, or something.
In any case, just changing the macro name solved it.

Sorry for the waste of bandwidth.  :-/

Jeff Verdegan
jverdega@cae.wisc.edu