Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: [Full-disclosure] Firefox 2.0.0.7 has a very serious calculation bug |
|---|---|
| Date: | Fri, 28 Sep 2007 22:08:15 +0200 (CEST) |
On Fri, 28 Sep 2007, Rodrigo Barbosa wrote:
volatile double a = 5.2; volatile double b = 0.1; main() { printf("%.16lf\n",a-b); }Isn't this the same issue pointed out by Brian Kim (double to float conversion) ?
There is no double to float conversion in the above code.
Look the results I get for the following code:
volatile double a = 5.2;
volatile double b = 0.1;
printf("%.16lf\n",a);
printf("%.16lf\n",b);
printf("%.16lf\n",(volatile double) 5.1);
printf("%.16lf\n",(volatile double)((float) 5.1));
printf("%.16lf\n",a-b);
There is no double to float conversion in your code, either. There is a float to double conversion, to which you point, but it has pretty much nothing to do with the discussed behavior of Firefox (or my code snippet), and produces a distinctive result (5.0999999046325684). I'm also puzzled as to why you typecast printf parameters to volatile. Floating point integers are inherently inaccurate; many numbers cannot be accurately represented in this format (5.2 being no exception) - and small errors are introduced and propagated through calculations. This is a well-documented and well-understood property, and really the only way such calculations could realistically be performed using small, constrained datatypes and sane FPU designs. It's not a security problem, either, unless a misguided application programmer expects the calculations to have some magical unconstrained precision (yet fails to use specialized scientific libraries to get close to this goal), and makes critical decisions based on these made up expectations. That's not a problem with Firefox, though. Really... http://en.wikipedia.org/wiki/IEEE_754 /mz _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
| Previous by Date: | Re: [Full-disclosure] Firefox 2.0.0.7 has a very serious calculation bug, Jimby Sharp |
|---|---|
| Next by Date: | Re: [Full-disclosure] Firefox 2.0.0.7 has a very serious calculation bug, Rodrigo Barbosa |
| Previous by Thread: | Re: [Full-disclosure] Firefox 2.0.0.7 has a very serious calculation bug, Rodrigo Barbosa |
| Next by Thread: | Re: [Full-disclosure] Firefox 2.0.0.7 has a very serious calculation bug, Jimby Sharp |
| Indexes: | [Date] [Thread] [Top] [All Lists] |