David Jones wrote: > After I wrote a blog article on this subject someone suggested I > raise the issue here. > > Currently, ECMA 262 3rd edition section 9.8.1, the ToString operator > permits implementations to vary in how they convert certain numbers > to strings. For example the number 5e-324 could legally be converted > as "3e-324", "4e-324", and so on up to "7e-324". > > This would permit an implementation to evaluate the following > expression as "undefined": > > ({5e-324:true})[5e-324] > > I do not think any reasonable implementation would have a good reason > for doing this. > > It also permits the value of 'a' to vary between implementations in > the following loop body: > > for(a in {5e-324:true}) {...} > > In order to ensure implementations all behave the same way I suggest > the note at end of section 9.8.1 be moved to normative status. As > far as I can tell, the text is essentially the same between ECMA 262 > 3rd edition and the Oslo draft published on 2008-07-04. > > Cheers, > drj
I don't mind specifying it if the implementations agree. Incidentally, this is a big problem with C and C++ right now. gcc will generate code for double x = <some floating-point expression>; double y = x; ... bool b1 = x == y; ... bool b2 = x == y; ... bool b3 = x == y; where b1 and b3 will evaluate to true and b2 to false (the results depend on its register allocation strategy). Waldemar _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss