ToString for Numbers: reducing variation.

[David Jones-18]

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

PS blog article at: http://drj11.wordpress.com/2008/07/11/javascript- 
using-numbers-as-table-keys-considered-harmful/
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Waldemar Horwat]

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@...
https://mail.mozilla.org/listinfo/es4-discuss