The main one I'm unsure about PRBool <- JSPackedBool, should i be treating JSPackedBool as PRBool?

What about defining JSBool and PRBool as bool under C++ or C99? This would simplify the patch.

Comment on attachment 337127 [details] [diff] [review] spidermonkey bugs >diff --git a/js/src/jsemit.cpp b/js/src/jsemit.cpp ... >-static JSBool >+static ptrdiff_t > EmitJump(JSContext *cx, JSCodeGenerator *cg, JSOp op, ptrdiff_t off) > { > JSBool extend; >@@ -1175,13 +1175,13 @@ EmitJump(JSContext *cx, JSCodeGenerator > > extend = off < JUMP_OFFSET_MIN || JUMP_OFFSET_MAX < off; > if (extend && !cg->spanDeps && !BuildSpanDepTable(cx, cg)) >- return JS_FALSE; >+ return NULL; ... > if (!AddSpanDep(cx, cg, pc, pc, off)) >- return JS_FALSE; >+ return NULL; In both change chunks the function should return (ptrdiff_t) -1, not NULL, to indicate an error.

pushed d518ddaac216

(In reply to comment #1) > What about defining JSBool and PRBool as bool under C++ or C99? This would > simplify the patch. It would also cause a whole lot of compile errors and cause the patch to be bigger. But the main problem is that it would also break API compatibility. I'd be all for eliminating internal prbools in favour of bools if we could somehow figure out what interal means.