ToString for Numbers: reducing variation.

[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