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
