Boost logo

Boost :

From: (noreply_at_[hidden])
Date: 2006-06-12 17:06:32

Bugs item #1505014, was opened at 2006-06-12 14:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: random
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jens Maurer (jmaurer)
Summary: Invalid code used for add w/ overflow checking

Initial Comment:
Discovered while working on our (Microsoft) C++

This is an e-mail thread about the bug we ran into.
The current Microsoft VC++ compiler does not causes
this to return incorrect values, but there is no
guarantee that this will be the case in the future as
we produce better optimizations.

If you need to contact me about this, my e-mail is

> FYI - this bug exists in at least versions of boost
>= 1.27.0
> (including the current one). Please see below for
details. It's a
> little unclear to us what the purpose of this
function is, but it
> appears to be doing a signed add and handling
overflow conditions, but
> it's doing to overflow detection incorrectly.
> Thanks,
> -Alex Thaman (Microsoft)
> _____________________________________________
> From: Russell Hadley
> Sent: Friday, June 09, 2006 3:00 PM
> To: Alex Thaman; Arjun Bijanki; Andy Rich
> Subject: RE: boost bug
> Just a slight spin on this: For the current boost
sources we aren't
> making a transformation in the compiler which
exposes the reliance on
> signed arithmetic overflow/underflow - this was
exposed in an older
> version - but potentially we could. It is a much
safer practice to
> test the ranges of the inputs to an arithmetic
expression if there is
> a danger of overflow rather than the output. The
compiler can
> potentially reorder any signed integer arithmetic
(algebraically) with
> out respect for signed overflow/underflow so
outputs have undefined
> semantics for that case. (off the cuff ex: cast
the inputs to
> unsigned and check their ranges.)
> Thanks.
> -R
> _____________________________________________
> From: Alex Thaman
> Sent: Friday, June 09, 2006 1:53 PM
> To: Arjun Bijanki
> Cc: Russell Hadley
> Subject: boost bug
> We ran into a bug in boost. In
> conformance\3rdPartyLibs\boost_1_2*_0
> p, there is a function called add_signed (do_add in
version > 1.27.0).
> It has the following code:
> template<>
> struct do_add<true>
> {
> template<class IntType>
> static IntType add(IntType m, IntType x,
IntType c)
> {
> x += (c-m);
> if(x < 0)
> x += m;
> return x;
> }
> };
> The problem is that it is relying on an overflow in
their logic to
> calculate the correct value. This is undefined in
most cases, and the
> optimizer does some logic here by calculating
intermediate values and
> using them and avoiding the overflow that this test
is expecting. It
> is pretty clear that they depend on overflow
behavior if you just do a
> quick refactor of this code:
> If (x + (c - m) < 0) return x + c
> Else return x + c - m
> Thanks,
> -Alex


You can respond by visiting:

Boost-bugs mailing list

Boost list run by bdawes at, gregod at, cpdaniel at, john at