Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!hplabs!pyramid!bjb
From: bjb@pyramid.pyramid.com (Bruce Beare)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Problem with LSC 4.0 debugger.
Message-ID: <85347@pyramid.pyramid.com>
Date: 25 Sep 89 03:22:04 GMT
References: <85031@pyramid.pyramid.com> <244@dbase.UUCP>
Reply-To: bjb@pyramid.pyramid.com (Bruce Beare)
Distribution: na
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 67

In article <244@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes:
>In article <85031@pyramid.pyramid.com>, bjb@pyramid.pyramid.com (Bruce Beare) writes:
>> The think C 4.0 debugger is not able to show stack variables for
>> functions that are 1 or more calling frames "up" the stack. 
>>
>>	
>>
>> This behavior of LSC's Debugger is silly. It has all of the information
>> it needs - it knows the stack offset of WINDid (it can display it if
>> we put a breakpoint in the function Cwindow:Iwindow - before calling 
>> CheckResource), and it knows how to trace through the stack frames.
>> It just doesn't bother to display the information.
>> 
>> I've discussed this with Think's support - Darell (sp?), and he has agreed
>> that this "would be a useful feature" and might be looked at in a future
>> release. My intention here is to raise the point for discussion and
>> hopefully convince Think that it is a real deficiency that should be
>> addressed soon.
>> 
>> Bruce Beare
>
>Does the word 'scope' ring a bell here?  K&R, 1st Ed., p. 76:
>
>"The scope of a name is the part of the program over which the name is
>defined.  For an automatic variable declared at the beginning of a function,
>the scope is the function in which the name is declared, and variables of 
>the same name in different functions are unrelated.  The same is true of
>the arguments of the function."
>
>Darell's reaction sounds like good salesmanship, but it also demonstrates
>why tech support doesn't write the software.
>
>Maybe I'm being unnecessarily harsh, but how about a law that says that
>before Symantec can sell someone a C compiler that that person has to 
>demonstrate competency in the language.  No, I take it back--that's not
>nice.  Scoping rules are a fairly advanced part of C and the issue is
>further clouded by Pascal's nested blocks--that is:
>
>	function what
>	var x:integer
>	
>		function who
>			GetResource(x)
>
>In pascal, the debugger can tell you what 'x' is inside 'who'.  C just
>doesn't work like that.  Let's move discussion of radical changes to
>the C language out of this newsgroup (rec.humor?).
>
>I'm sorry; I apologize in advance if I'm being offensive.  Call it my
>mood today and the way this posting hit me.  I'll feel better after the
>weekend.
>
>/alastair/

I am not sure exactly what position you are taking. I think that you are
saying "If the program can't see the variable from the current PC, then
the debugger should not be able to display it." If this is not your position,
I'll "apologize in advance."

I certainly don't agree with the above statement. 
	1) The debugging programmer needs all the help that they can get. 
	2) The "context argument" can be turned around for the purposes of this
	   argument. i.e. "The debugger should be able to set the context 
	   in which the memory display/modify request in the data window
	   will be interpreted/executed." This means that when you do a
	   "set context" on a line in the data window, the line will
	   obey all of the scope rules for the selected context.