|Re: [eigen] Checking for integer overflow in size computations|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Checking for integer overflow in size computations
- From: Eamon Nerbonne <eamon@xxxxxxxxxxxx>
- Date: Mon, 17 Oct 2011 10:40:30 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=6r2JWKqbw2/+IzTq6pHgSJRcj0YVHAhY3emwIVbIbOg=; b=Y04d/rr2HjWw7JO6NPGsHaMc/mjAOgUxtbVR+SfpEt2l9vNz2h1PmmF8U4XsvnLuKW 4JMk2uOufe/Oo9BrRkN4lLCIBHRIsT0BCOf+3seu0Fs4itVNmzazExxJ59r730dNYGZU UPlfjxtGND4pZI5W5nZbnqxhcqDvCvrR1N5yk=
If you're building without exceptions and an exception gets thrown, 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>
2011/10/16 Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>:
> On 16.10.2011 22:21, Benoit Jacob wrote:I don't know that all platforms have an integer type twice bigger than size_t?
>> 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?
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.
Both Mozilla and KDE are examples of large projects building with
> 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
>> 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.
-fno-exceptions. That's the kind of fact that makes me uncomfortable
about C++ exceptions.