JavaScript math errors

[GoogleCodeExporter]

Reported by Hirofumi Ohta. We really need to get some sort of unit testing up 
for the js module. For now, he reports the following differences:

http://www.floodgap.com/software/classilla/bleh/math/

> I report two samples of the JavaScript that return incorrect values on the 
Classilla 9.2 only; the correct values are returned on the Mozilla 1.3.1 (Mac 
OS 9.2.2), the Internet Explorer 5.1.7 (Mac OS 9.2.2), the Safari, the FireFox, 
etc.

This is an obvious regression.

Original issue reported on code.google.com by classi...@floodgap.com on 30 Jun 2010 at 11:15

[GoogleCodeExporter]

Some other things to test:

http://www2.masashi.ne.jp/ohta/circular.html

Original comment by classi...@floodgap.com on 30 Jun 2010 at 11:16

[GoogleCodeExporter]

I updated the test case. Several things are now apparent:

- The number and math is handled correctly internally (see updated test case); 
there is no rounding UNTIL the value is passed for display.

- This is not an optimizer problem; optimization off made no difference.

- All versions of Classilla do this wrong, even back to 9.0, but WaMCom does it 
right.

Original comment by classi...@floodgap.com on 8 Aug 2010 at 1:09

[GoogleCodeExporter]

toString() also doesn't work. Maybe that's our problem?

Original comment by classi...@floodgap.com on 8 Aug 2010 at 1:12

[GoogleCodeExporter]

toString() rounds it up to 1.2e+12. Hmmmmmm.

Original comment by classi...@floodgap.com on 8 Aug 2010 at 1:14

[GoogleCodeExporter]

WaMCom's toString() renders it correctly.

Original comment by classi...@floodgap.com on 8 Aug 2010 at 1:15

[GoogleCodeExporter]

Some additional testing implies that it is not handling the math correctly 
either.

We can ship with this bug, it's never worked properly. But it sure is annoying 
because there's no technical reason why it should be this way. Comparison of 
1.2 and Classilla 9.0 sources showed little difference; similarly, the .xml 
project settings are also the same. Substitution of the 1.2 JavaScript shlb 
into 9.0 corrects the problem, so it is clearly something specific to the 
interpreter.

Downgrading to high. Still technically a regression.

Original comment by classi...@floodgap.com on 8 Aug 2010 at 10:22

• Added labels: Priority-High
• Removed labels: Priority-Critical

[GoogleCodeExporter]

Switching to fdlibm makes no difference.

Changing math.h to fp.h makes no difference.

Original comment by classi...@floodgap.com on 13 Jul 2012 at 7:28

[GoogleCodeExporter]

My lates build seems to have fixed this issue. Math.pow(2,50) returns 
1125899906842624 instead of some value with lots of zeros. It seems that the 
issue is related to Classilla source used long long in JSRef library where as 
in WaCom source did not. I have suspect that to be the culprit because it 
seemed it calculated fine upto Math.pow(2,49) but from Math.pow(2,50) it 
returned weird results. I had to modify a couple of files in the library to 
make it compiles without using long long type for 64 bit values. On the other 
hand, Mozilla's bugzilla has an entry that mentions about that Metroworks 
CodeWarrior 7.1 produces incorrect assembly codes when you multiply 
mix-and-matched signed/unsigned int32/int64 values while 7.0 is OK and 7.2 
fixes the bug. We should test with 7.2 if we could hand on a 7.2 update file. 
Otherwise, I will tidy up the modifications and upload here. As soon as this is 
confirmed, this would be my first contribution to Classilla. :)

https://bugzilla.mozilla.org/show_bug.cgi?id=119314

Original comment by terr...@gmail.com on 5 Dec 2014 at 1:24

[GoogleCodeExporter]

Nice find. I look forward to your changes.

Unfortunately, I don't have access to 7.2 and it would be nice to fix this bug 
anyway even though it's a Metrowerks problem.

Original comment by classi...@floodgap.com on 5 Dec 2014 at 5:19

[GoogleCodeExporter]

I have disabled JS_HAVE_LONG_LONG to make it uses its internal 64-bit integer 
emulation instead of actual long long type which made it not compilable. So I 
had to made some modifications to other files as well. Since the emulation uses 
struct of two 32 bit unsigned integer, some of the codes assumed Int64 type to 
be of long long or something and used native operator to do calculation. I have 
AFAIK modified following files;

mozilla:js:src:jscpucfg.h
mozilla:js:src:jsgc.c
mozilla:js:src:prmjtime.c
mozilla:js:jsd:jsd_step.c

I placed files in actual hierarchy comparable to the mozsrc. And I have used 
DropStuff 6.0 since that is on my build system. So if it cannot be 
decompressed, let me know. Then I will try to sort it out.

[Related URLs]
* Bug 119314 - JS assertion in jsdtoa.c when built with CodeWarrior Pro 7.1 
compilers
https://bugzilla.mozilla.org/show_bug.cgi?id=119314

* Bug 3616 - [PP]long long support in Mac NSPR
https://bugzilla.mozilla.org/show_bug.cgi?id=3616

* Metrowerks CodeWarrior 7.2 update
Page URL: 
http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_UPDATES_MAC
Download URL: 
http://cache.freescale.com/lgfiles/updates/ARCHIVES/CWMacOS7/C++_MacOS_PPC_Pro7.
2.sit

Original comment by terr...@gmail.com on 6 Dec 2014 at 7:35

Attachments:

• [issue 133.sit](https://storage.googleapis.com/google-code-attachments/classilla/issue-133/comment-10/issue 133.sit)