Closed
Bug 293782
Opened 20 years ago
Closed 20 years ago
Local variables can cause predefined function object properties to be undefined
Categories
(Core :: JavaScript Engine, defect, P1)
Core
JavaScript Engine
Tracking
()
VERIFIED
FIXED
mozilla1.8beta2
People
(Reporter: jwatt, Assigned: brendan)
References
Details
(Keywords: js1.5)
Attachments
(3 files)
|
31.68 KB,
patch
|
shaver
:
review+
shaver
:
approval1.8b2+
|
Details | Diff | Splinter Review |
|
33.27 KB,
patch
|
Details | Diff | Splinter Review | |
|
30.60 KB,
patch
|
shaver
:
review+
shaver
:
approval1.8b2+
|
Details | Diff | Splinter Review |
If a function has a local variable with the same name as a predefined function
object property (e.g. apply, call and name) then those properties will be
undefined for that function object. Test using the following:
javascript:function f(){var name=1;};alert(f.name);
| Assignee | ||
Updated•20 years ago
|
Assignee: general → brendan
Flags: blocking1.8b3+
Keywords: js1.5
Priority: -- → P3
Target Milestone: --- → mozilla1.8beta3
| Assignee | ||
Updated•20 years ago
|
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: mozilla1.8beta3 → mozilla1.8beta2
| Assignee | ||
Comment 1•20 years ago
|
||
Yay, this patch removes the XXX'd hacks in jsinterp.c (SetFunctionSlot) and
jsobj.c (with_GetProperty) that try with too much code to work around the
pre-ECMA pollution of function objects with properties, used by the compiler
and by Call object reflection, describing their args and local vars.
/be
Attachment #183623 -
Flags: review?(shaver)
Comment 2•20 years ago
|
||
Comment on attachment 183623 [details] [diff] [review]
Fix SpiderMonkey to hide arg/var properties of function objects
I like -- perhaps love -- everything here but "FUNNY". I appreciate a good
function pun, but wonder if _ACTIVATION or some such might be clearer.
(Especially given the now-dead, but long-lasting, CHECK_FOR_FUNNY_ID macro,
though that might only matter to you and me.)
Not enough to keep this from hitting the tree, though, as it is indeed truly
righteous.
r+a=shaver
Attachment #183623 -
Flags: review?(shaver)
Attachment #183623 -
Flags: review+
Attachment #183623 -
Flags: approval1.8b2+
| Reporter | ||
Comment 3•20 years ago
|
||
(In reply to comment #2)
> (From update of attachment 183623 [details] [diff] [review] [edit])
> I like -- perhaps love -- everything here but "FUNNY". I appreciate a good
> function pun, but wonder if _ACTIVATION or some such might be clearer.
huh, yeah, that would have been clearer to me at least.
Comment 4•20 years ago
|
||
Checking in 10.1.6.js;
/cvsroot/mozilla/js/tests/js1_5/Function/10.1.6.js,v <-- 10.1.6.js
initial revision: 1.1
Flags: testcase+
| Assignee | ||
Comment 5•20 years ago
|
||
- Renamed _FUNNY => _HIDDEN.
- Fixed a leftover js_LookupProperty in Function that was looking for duplicate
formal parameters -- of course it must now be js_LookupPropertyWithFlags(...,
JSLOOKUP_HIDDEN, ...).
- Robusticated call_resolve to insist that any hidden property found in the
callee or a prototype of the callee came from the same function as the callee's
fp->fun. Necessary since (mutable) __proto__ was added.
/be
| Assignee | ||
Comment 6•20 years ago
|
||
Fixed. Marking deps fixed too. Hooray!
/be
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
| Assignee | ||
Comment 7•20 years ago
|
||
There's no way around it, given id uniquely identifying a property in an
object: to hide function formarl parameter and local variable properties in a
disjoint set of properities requires a disjoint set of ids. Hence this patch,
which undoes the regression of bug 137000. Checking in shortly.
/be
Attachment #183781 -
Flags: review?(shaver)
Comment 8•20 years ago
|
||
Comment on attachment 183781 [details] [diff] [review]
followup fix
r+a=shaver.
Attachment #183781 -
Flags: review?(shaver)
Attachment #183781 -
Flags: review+
Attachment #183781 -
Flags: approval1.8b2+
| Assignee | ||
Comment 9•20 years ago
|
||
I checked in the followup fix, with one slight tweak to jsemit.c (to test !ok
and break if so after the call to js_LookupHiddenProperty for the native obj
case in js_LookupCompileTimeConstant).
/be
Comment 10•20 years ago
|
||
latest patch looks to be causing tinderbox orange!
| Assignee | ||
Comment 11•20 years ago
|
||
Sorry about that -- over-reliance on the JS testsuite, and neither shaver nor I
remembered the JS_CompileUCFunctionForPrincipals API impl, which defines formal
parameters.
/be
| Reporter | ||
Comment 12•20 years ago
|
||
The inner variables of functions still show up in for-in statements. Try
function f(){var a, b;}
for (prop in f) alert('f['+prop+'] == '+f[prop])
Should I file a separate bug, or does this need to be reopened?
| Assignee | ||
Comment 13•20 years ago
|
||
(In reply to comment #12)
> The inner variables of functions still show up in for-in statements. Try
>
> function f(){var a, b;}
> for (prop in f) alert('f['+prop+'] == '+f[prop])
>
> Should I file a separate bug, or does this need to be reopened?
Fixed. This was just a matter of removing JSPROP_ENUMERATE attributes passed to
js_AddHiddenProperty for args and vars, per ECMA-262 Ed. 3, 10.1.3 and 10.2.3.
/be
| Reporter | ||
Comment 14•20 years ago
|
||
Brendan, the problem seems to still exist in a build I made in the last hour or so.
| Assignee | ||
Comment 15•20 years ago
|
||
jwatt: thanks for catching this -- one JSPROP_ENUMERATE was left behind. Fixed.
/be
Status: RESOLVED → VERIFIED
Comment 16•20 years ago
|
||
testcase for enumerating function local variables.
Checking in 10.1.6-01.js;
/cvsroot/mozilla/js/tests/js1_5/Function/10.1.6-01.js,v <-- 10.1.6-01.js
initial revision: 1.1
done
You need to log in
before you can comment on or make changes to this bug.
Description
•