6 ms·

http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=2355f01709eadfd5350c510cdb095b4e3f71f17c http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=2

by wingo 14y ago

http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=2355f01709eadfd5350c510cdb095b4e3f71f17c http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=2... Fixed by Mark H Weaver, on Fri, 7 Dec 2012. Avoid signed integer overflow in scm_product * libguile/numbers.c (scm_product): Avoid signed integer overflow, which modern C compilers are allowed to assume will never happen, thus allowing them to optimize out our overflow checks. * test-suite/tests/numbers.test (*): Add tests.

cwzwarich 14y ago
Checking for signed overflow by first performing signed overflow is a great C antipattern.
- regehr 14y ago
  Exactly. I've seen plenty of overflow detection libraries that do precisely this. The undefined overflow plus the lack of access to CPU flags makes a pretty good argument against doing this stuff at the C/C++ level.
gjm11 14y ago
Interesting, but given that the code in question computes (expt 2 488) as the square of (expt 2 244), is there actually any way for that bug to cause the observed symptoms? (2^244 is being shown as zero. 2^488 is being shown as non-zero; presumably the right value though I haven't actually checked. If 2^244 is actually being computed as zero, then unless what's happening somehow depends on the depth of the stack -- surely not possible if this bug is the cause -- 2^488 should be computed as zero squared, which is zero.)
- wingo 14y ago
  Sure, it's possible. The sequence of multiplications chosen to reach the exponent is different, so these expressions take different paths through scm_integer_expt.
  - gjm11 14y ago
    But the sequence of multiplications chosen to reach the exponent isn't different. What the user's expt function does, when asked to compute (expt 2 488), is to compute (expt 2 244) and then square it. When it computes (expt 2 244) it does the exact same sequence of multiplications as if you just asked for that directly from the REPL. What am I missing here?
qznc 14y ago
A nice example for Regehr's post: C and C++ Aren’t Future Proof http://blog.regehr.org/archives/880 http://blog.regehr.org/archives/880
- regehr 14y ago
  Awesome, I've added a link to the bottom of the post.
peteri 14y ago
I currently think the C compiler vendors have gone too far with this. Although the specification says this behaviour is undefined in practice I used to map the undefined portion to being whatever my hardware did, not whatever the compiler felt like this week. This ruins the C as a portable assembler use case and means if I was doing this sort of work I'd probably write these sort of routines in assembler rather than trying to fight with versions of C compiler.
- colanderman 14y ago
  ...how was C "portable" assembler if its semantics depended on the underlying hardware? That's by definition unportable.

by wingo 14y ago

cwzwarich 14y ago

Checking for signed overflow by first performing signed overflow is a great C antipattern.

regehr 14y ago
Exactly. I've seen plenty of overflow detection libraries that do precisely this. The undefined overflow plus the lack of access to CPU flags makes a pretty good argument against doing this stuff at the C/C++ level.

gjm11 14y ago

Interesting, but given that the code in question computes (expt 2 488) as the square of (expt 2 244), is there actually any way for that bug to cause the observed symptoms? (2^244 is being shown as zero. 2^488 is being shown as non-zero; presumably the right value though I haven't actually checked. If 2^244 is actually being computed as zero, then unless what's happening somehow depends on the depth of the stack -- surely not possible if this bug is the cause -- 2^488 should be computed as zero squared, which is zero.)

wingo 14y ago
Sure, it's possible. The sequence of multiplications chosen to reach the exponent is different, so these expressions take different paths through scm_integer_expt.
- gjm11 14y ago
  But the sequence of multiplications chosen to reach the exponent isn't different. What the user's expt function does, when asked to compute (expt 2 488), is to compute (expt 2 244) and then square it. When it computes (expt 2 244) it does the exact same sequence of multiplications as if you just asked for that directly from the REPL. What am I missing here?

qznc 14y ago

A nice example for Regehr's post: C and C++ Aren’t Future Proof http://blog.regehr.org/archives/880 http://blog.regehr.org/archives/880

regehr 14y ago
Awesome, I've added a link to the bottom of the post.

peteri 14y ago

I currently think the C compiler vendors have gone too far with this. Although the specification says this behaviour is undefined in practice I used to map the undefined portion to being whatever my hardware did, not whatever the compiler felt like this week. This ruins the C as a portable assembler use case and means if I was doing this sort of work I'd probably write these sort of routines in assembler rather than trying to fight with versions of C compiler.

colanderman 14y ago
...how was C "portable" assembler if its semantics depended on the underlying hardware? That's by definition unportable.