Created attachment 400401 [details] [diff] [review] patch ../jsfun.cpp: In member function ‘int JSFunction::sharpSlotBase(JSContext*)’: ../jsfun.cpp:1802: warning: ‘index’ may be used uninitialised in this function This one seems reasonable -- js_LookupLocal isn't guaranteed to initialise 'i' (hopefully it always does due to some jstracer-specific invariant that GCC doesn't know about). Using -1 as default seems reasonable since that's sharpSlotBase()'s default return value. ../jsnum.cpp:1347: warning: ‘bdr.BinaryDigitReader::digit’ may be used uninitialised in this function Seems like GetNextBinaryDigit() will always initialize 'digit', given the other values in 'bdr'. I used 0 as the default initialization value, seems the most obvious (and should 'digit' truly fail to be initialized, 0 will be correct half the time :) ../jsregexp.cpp:2009: warning: ‘core’ defined but not used Removed this variable.
Attachment #400401 - Flags: review?(brendan)
Attachment #400401 - Flags: review?(brendan) → review+
(I hope no compiler warns about initializing unsigned types with -1...)
Good point -- you want me to change it to zero?
No,the caller (js_Execute) will defend given -1. At most we want uintN(-1) sa the initializer, but I'm not sure you will get a warning with -1. Try it and see? /be
I didn't get a warning with the naked -1, but I thought other compilers might warn, and the (uintN) cast is useful documentation, so I included the cast. http://hg.mozilla.org/tracemonkey/rev/2fde438e64ff
Prefer C++ style casts now (uintN(-1) as I wrote in comment 4, not (uintN)-1). Nit for sure, but rs=me on followup change. I don't see the cast as documentation in any event. The variable's type is the same, and nothing is in a comment, so it's just redundancy. /be
Follow-up that changes the cast syntax: http://hg.mozilla.org/tracemonkey/rev/2a3c66f0a36c
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.