|[eigen] Checking for integer overflow in size computations|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen <eigen@xxxxxxxxxxxxxxxxxxx>
- Subject: [eigen] Checking for integer overflow in size computations
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Sun, 16 Oct 2011 16:21:52 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=VGuNWQKrIAYHitK464Vw2JLvPIN7fL1UCxt9RKGxDYU=; b=Cem4ng57QHQuD+4kBILmw06tutx6XeLO8Ina/qt3hCVqtnOH3DncYAFhH9ywxGyD8D GS6Ch+q7cQwAh9Xf6uB1CBk3ThuCK8gWpcWBzvXjvv+uxjsIiPOEId2O0Ppyu5IC4xLc KCcWHoLkoF+7AFW1FJUj+ARINNmLiaYIzCDqk=
This is about Bug 363.
We weren't checking for integer overflow in our size computations, at
2 different levels:
1) Index size=rows*cols computations in PlainObjectBase.h
2) size_t byte_size=size*sizeof(Scalar) computations in Memory.h
This is fixed in the default branch (1 is fixed by f76f77b7d086, 2 is
fixed by 25ba289d5292, unit test added by f76f77b7d086)
Note that there is a small performance overhead associated with that.
I tried to minimize it, but there is still 1 integer division in the
size=rows*cols overflow check. I hope that's still negligible compared
to the cost of malloc.
Like the standard behavior of operator new and of our own aligned_new
routines, these checks throw std::bad_alloc on error and don't do
anything else. In particular, we still don't guarantee that
aligned_new returns null on error. It feels weird to me to rely
entirely on exceptions to report these errors, but this is how c++
works (as long as one doesn't use nothrow-new) and what we've been
doing. Is this OK?
I feel that this should be merged to the 3.0 branch. Do you agree?