Mark H Weaver <m...@netris.org> writes: >> + for (result = 0, left = c_count; result < c_count; ) > > If 'c_count's does not fit in a 'ssize_t', then this loop will go > forever and 'result' will wrap around to negative numbers and undefined > C behavior.
Having just consulted the relevant C standards, I see that I was wrong to claim that the loop will spin forever. If a signed integer is compared with an unsigned integer of equal rank, the signed integer is converted to unsigned first. The latter part of my statement (about undefined behavior) was true, and invalidates any other predictions. If 'result' overflows (and it will if 'c_count' does not fit in a 'ssize_t' and nothing else goes wrong) then the behavior of the program is completely undefined. Modern C compilers are increasingly fond of taking advantage of that fact, as demonstrated by the recent discovery that they were optimizing out our overflow checks. http://stackoverflow.com/questions/14495636/strange-multiplication-behavior-in-guile-scheme-interpreter http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=2355f01709eadfd5350c510cdb095b4e3f71f17c Mark
