124468 - JS_IsNativeFrame should return !fp->script

Status: RESOLVED FIXED

(Other Applications Graveyard :: Venkman JS Debugger, defect)

Description

[Robert Ginda]

Index: jsdbgapi.c
===================================================================
RCS file: /cvsroot/mozilla/js/src/jsdbgapi.c,v
retrieving revision 3.30
diff -u -r3.30 jsdbgapi.c
--- jsdbgapi.c  3 Oct 2001 06:39:26 -0000       3.30
+++ jsdbgapi.c  8 Feb 2002 21:37:53 -0000
@@ -612,7 +612,7 @@
 JS_PUBLIC_API(JSBool)
 JS_IsNativeFrame(JSContext *cx, JSStackFrame *fp)
 {
-    return fp->fun && fp->fun->native;
+    return !fp->script;
 }
 
 /* this is deprecated, use JS_GetFrameScopeChain instead */

Comment 1

[Mike Shaver (:shaver emeritus)]

Didn't brendan already lecture us as to the fact that nativeness and scriptiness
were not mutually exclusive, in frames?

If you want to test the opposite of JS_IsScriptFrame, let's not change
JS_IsNativeFrame, but add another call.

Other question, while we're in here: do we instead want JS_GetFrameScript and
JS_GetFrameNative, such that debuggers can use those values to provide
additional information?  (With a little bit of love from bfd or whatever, they
could tell you which native you were calling through, for example.)

Then a NULL return from JS_GetFrameNative or JS_GetFrameScript would be able to
signal that there was no native or script, respectively, associated with the frame.

Comment 2

[Brendan Eich [:brendan]]

shaver: what frame has neither a script, nor a fun (native, if !script)?  The
only ones are internal to the compiler, IIRC.  Is your point that the debugger
should be checking !JS_IsScriptFrame in some situation, or even
JS_IsScriptFrame, where it currently checks for a native function activation
frame and messes up the "eval called from a native" case (the one where eval's
frame gets its fun member copied from the caller's)?

/be

Comment 3

[Robert Ginda]

We don't *have* JS_IsScriptFrame.  Is there ever a frame which is both native
and script, other than this eval-in-stack-frame business?

Comment 4

[Mike Shaver (:shaver emeritus)]

I have no idea what my point was.  sr=shaver, though.

Comment 5

[John Bandhauer]

I'm convinced. r=jband. Shaver's comment suggests little weight to his sr= :)

Comment 6

[Mike Shaver (:shaver emeritus)]

I notice you're not man enough to step up with an sr=, though, instead
preferring to hide behind a wussy r=!

(I think I was confusing heavyweight/lightweight with native/script, in
brendan's previous missive on related topics.  I could pretend that I'm
concerned about the eval-in-stackframe case, but nobody'd buy it at this point.)

Comment 7

[John Bandhauer]

r/sr=jband

Comment 8

[Robert Ginda]

checked in.