475925 - inconsistent [[Array]] method handling of [Undefined] values

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[peter seliger]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5



Hallo,


I wanted to ask if mozillas implementation of array
-iterators/accessors/generators and theirs handling
of [undefined] values meets mozillas own specifications
as for instance briefly described here for [filter] ...

[https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Array/filter#Description]

... or not - and if so why than within gecko different
appearances of [undefined] array members get handled
not consistently.

my expectation was that for this given test ...

/*
	to be run in [http://jconsole.com/]
*/
var arr01 = new Array(9);
var arr02 = [,,,,,,,,,];
var arr03 = [window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined];

	print("arr01.length : " + arr01.length);
	print("arr02.length : " + arr02.length);
	print("arr03.length : " + arr03.length);

	print("arr01.toSource() : " + arr01.toSource());
	print("arr02.toSource() : " + arr02.toSource());
	print("arr03.toSource() : " + arr03.toSource());

arr01 = arr01.filter(function(elm){return(!elm);});
arr02 = arr02.filter(function(elm){return(!elm);});
arr03 = arr03.filter(function(elm){return(!elm);});

	print("arr01.length : " + arr01.length); // 0 - as expected.
	print("arr02.length : " + arr02.length); // 9 - not expected at all - does mozilla fail here?
	print("arr03.length : " + arr03.length); // 9 - not expected at all - does mozilla fail here?
/*
	print("arr01.toSource() : " + arr01.toSource());
	print("arr02.toSource() : " + arr02.toSource());
	print("arr03.toSource() : " + arr03.toSource());
*/

... each of the given arrays is expected to be entirely
empty, faeturing a length of zero. for the above provided
test this behavior not only can be found for [filter] but
for every [[Array]] method where handling of [undefined]
values matters.

who is right mozilla or myself? ...


Array.prototype.filter = (function (fct, target) { // [filter] by "while"

	var arr = [];
	if (typeof fct == "function") {
		target = (((typeof target == "undefined") || ((typeof target == "obj") && !target)) ? (null) : (target));
		var i = 0, elm, len = this.length;
		while (i < len) {
			elm = this[i];
			if (typeof elm != "undefined") {
				if (fct.call(target, elm, i, this)) {
					arr.push(elm);
				}
			}
			++i;
		}
	} else {
		throw (new TypeError("1st argument needs to be a function type."));
	}
	return arr;
});

var arr01 = new Array(9);
var arr02 = [,,,,,,,,,];
var arr03 = [window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined];

arr01 = arr01.filter(function(elm){return(!elm);});
arr02 = arr02.filter(function(elm){return(!elm);});
arr03 = arr03.filter(function(elm){return(!elm);});

print("arr01.length : " + arr01.length); // 0 - as expected
print("arr02.length : " + arr02.length); // 0 - as expected
print("arr03.length : " + arr03.length); // 0 - as expected


... or did I get something wrong?


kind regards - Peter Seliger - [e-mail]



Reproducible: Always

Steps to Reproduce:
1a) var arr01 = new Array(9);
2a) var arr02 = [,,,,,,,,,];
3a) var arr03 = [window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined, window.undefined];

1b) arr01 = arr01.filter(function(elm){return(!elm);});
2b) arr02 = arr02.filter(function(elm){return(!elm);});
3b) arr03 = arr03.filter(function(elm){return(!elm);});

Actual Results:  
1c) alert(arr01.length); // alerts 0
2c) alert(arr02.length); // alerts 9
3c) alert(arr03.length); // alerts 9


Expected Results:  
1d) alert(arr01.length); // will alert 0
2d) alert(arr02.length); // expected to alert 0
3d) alert(arr03.length); // expected to alert 0

Comment 1

[Nochum Sossonko [:Natch]]

Attachment: reporter's testcase

This seems to work fine for me, and is consistent, the length should be 9.

Comment 2

[Mike Shaver (:shaver emeritus)]

Per ECMA, elisions in array literals do not create properties; you can test this with the "in" operator (we used to, but we fixed that bug).  Providing the value "undefined" in the literal means to create a property with that value.

(filter and the other array 'extras' only operate on properties that are present.)

Comment 3

[Nochum Sossonko [:Natch]]

The toSource, though changed in 3.1, though it's not this bug and it's probably more accurate in 3.1 now. See the testcase.

Comment 4

[Mike Shaver (:shaver emeritus)]

Yes, it's correct now.

Comment 5

[peter seliger]

(In reply to comment #4)
> Yes, it's correct now.

and what does this mean - does the current available script engine handle
the provided testcase correctly or not - I'm still sure handling of values
that should be considered to be [undefined] is not implemented consistently;
therefore buggy.

Comment 6

[Mike Shaver (:shaver emeritus)]

Reading a property that is not present produces "undefined", but it doesn't mean that there's a property named that.  You can see this with objects as well:

o = {a:"a", "b":b }
var c = o.c;
var hasC = ("c" in o); // will be false

Comment 7

[peter seliger]

(In reply to comment #6)

ok, I think I could follow and even can accept Your argumentation.
but if You got it implemented correctly then at least the google
chrome v8 guys got it partly wrong, since my first example in both
engines runs with different results.

thanks a lot - Peter Seliger

Comment 8

[peter seliger]

finally: [http://code.google.com/p/v8/issues/detail?id=218]

EOT - Peter