List: | Commits | « Previous MessageNext Message » | |

From: | Kristian Nielsen | Date: | October 27 2007 9:37am |

Subject: | Re: bk commit into 5.0 tree (knielsen:1.2488) BUG#31799 | ||

View as plain text |

Sergei Golubchik <serg@stripped> writes: > On Oct 24, knielsen@strippedwrote: >> ChangeSet@stripped, 2007-10-24 09:26:25+02:00, knielsen@ymer.(none) +4 -0 >> BUG#31799: Scrambled number output due to integer overflow >> >> An integer overflow in number->string conversion caused completely >> wrong output of the number LONGLONG_MIN with gcc 4.2.1. >> >> Fixed by eliminating the overflow, using only operations that are >> well-defined in ANSI C. > > Where does the standard say that the result is undefined ? > I wasn't able to find it :( My (old, second edition) of Stroustrups C++ book says in the reference manual, r.5: "The handling of overflow and divide check in expression evaluation is implementation dependent." and in r.3.6.1: "Unsigned integers ... obey the laws of arithmetic modulo 2**n ... This implies that unsigned arithmetic does not overflow." For ANSI C, my Kernighan and Ritchie says in the reference manual A7 (my translation back to English from a poorly translated Danish edition): "Handling of overflow, division control, and other exceptions in expression evaluation is not defined in the laguage." and in A4.2: "Unsigned integers ... obey the laws of arithmetic modulo 2**n ... so therefore arithmetic on an unsigned value never overflows." > Regards / Mit vielen Grüssen, > Sergei Thanks for reviewing, btw. GCC is doing some really interesting optimizations in that code. It is combining the two loops into one, apparently realising that they are exactly the same except for type sizes. And I *think* what is happening is that in the (val < 0) case, GCC realises that the loop will always be run at least once, so it unrolls the first iteration of the loop, skipping the first loop check, and also in the first iteration divides by -10 instead of 10 to avoid having to do the negation of val. I guess it is this last divide by negative number that causes overflow problems for LONGLONG_MIN. (and btw it does the constant divisions by multiplication of the corresponding fraction using fixed-point arithmetics I believe). But as far as I can see, it _seems_ that GCC is not violating any of the C standard... - Kristian.

Thread | ||
---|---|---|

• bk commit into 5.0 tree (knielsen:1.2488) BUG#31799 | knielsen | 24 Oct |

• Re: bk commit into 5.0 tree (knielsen:1.2488) BUG#31799 | Sergei Golubchik | 26 Oct |

• Re: bk commit into 5.0 tree (knielsen:1.2488) BUG#31799 | Kristian Nielsen | 27 Oct |

• Re: bk commit into 5.0 tree (knielsen:1.2488) BUG#31799 | Sergei Golubchik | 29 Oct |