|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: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Sun, 16 Oct 2011 18:36:37 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tc/654XG2+S9MDP3U7ncNIxqjJxUUiibEVg16u6StGc=; b=YjNZbDCBipO0U5cToAhzhUa40KbxK38zoVTKCWESq5Ig4cJeRHL+C4OP/hcF9r6B5g VSxGdt/fG/Jvv2Npu1ch6oHiJiyiGv32l1+i/U1vh1gFSiyhuePCetvOCyiw27newmM3 HObW+UPvPfJsAiipNtZV5BBLu+MBDyis3glD4=
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
>> 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.