Re: [eigen] Checking for integer overflow in size computations

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2011/10/17 Eamon Nerbonne <eamon@xxxxxxxxxxxx>:
> If you're building without exceptions and an exception gets thrown,

It's impossible to compile without exceptions code that explicitly
throws exceptions, as that results in a compilation error:

a.cpp: In function ‘int main()’:
a.cpp:5:24: error: exception handling disabled, use -fexceptions to enable

For this reason, currently in Eigen our code throwing exceptions is
#ifdef EIGEN_EXCEPTIONS which means it's not compiled at all when
exceptions are disabled.

That said, I tried a simple c++ program with a huge new[] to get an
exception thrown for me, compiled with -fno-exceptions, and that
indeed worked: a std::bad_alloc exception was thrown and killed my
test program.

My understanding is that the only way to get exactly the same behavior
from code that compiles with -fno-exceptions would be to call into
code that was compiled with exceptions. A way to simulate that is to
just do int *a = new int[size_t(-1)];

Patch coming.

Benoit

> it just
> means app termination (unless you're being really weird and catching the
> exception anyhow, not sure what happens then...), which is probably the
> right behavior in face of OOM anyhow.
>
> Also, even if exceptions are off by default in some projects, it's really
> handy to use them anyhow, since they make debugging that easier - i.e. a
> scenario in which devs can easily trigger on exceptions, regardless of
> wether the subsequent cleanup will honor destructors or not.  By constrast,
> a nullptr return value won't necessarily be easy to notice unless
> potentially much later.
>
> --eamon@xxxxxxxxxxxx - Tel#:+31-6-15142163
>
>
> On Mon, Oct 17, 2011 at 00:36, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
> wrote:
>>
>> 2011/10/16 Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>:
>> > On 16.10.2011 22:21, Benoit Jacob wrote:
>> >>
>> >> 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.
>> >
>> > I have not looked into your patch yet, but wouldn't a multiplication in
>> > int64/int128 also do the job?
>>
>> I don't know that all platforms have an integer type twice bigger than
>> size_t?
>>
>> On x86-64 are there 128 bit integers? I didn't know that.
>> Also I'm afraid there might exist 32bit platforms without 64bit integers..
>>
>> > I guess that would be much cheaper than a
>> > division. Anyways I would agree that the overhead should be negligible..
>> > If
>> > someone really cares for that overhead, we might introduce a flag such
>> > as
>> > EIGEN_DONT_CHECK_INTEGER_OVERFLOW.
>> >
>> >> 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 don't want to start a philosophical discussion about exceptions vs
>> > return-type checking, but honestly I guess that the C++ way is much more
>> > reliable, since about 99% of malloc users hardly ever check for NULL
>> > pointers ("Come on, how likely is it that I can't get ** MB?").
>> > Furthermore, I guess hardly anyone disables exceptions in C++, unless he
>> > really knows what he's doing.
>>
>> Both Mozilla and KDE are examples of large projects building with
>> -fno-exceptions. That's the kind of fact that makes me uncomfortable
>> about C++ exceptions.
>>
>> Benoit
>>
>>
>
>