November 04, 2008
Christopher Wright wrote:
> Andrei Alexandrescu wrote:
>> Jarrett Billingsley wrote:
>>> On Tue, Oct 28, 2008 at 7:21 AM, bearophile <> wrote:
>>>> This document from experience says that integral overflow bugs are a significant percentage of the total:
>>> No, it says array-out-of-bounds errors, dereferencing null pointers,
>>> accessing uninitialized variables _and_ integer overflows together
>>> represent 50% of the bugs.  I don't know about you but I run into
>>> those first three cases (well.. two, since there aren't uninitialized
>>> variables in D) waaaaay more than I do integer overflows.
>> I think the frequency of a bug should be multiplied with the trouble it takes to fix it. Frequency alone isn't terribly relevant.
>> Andrei
> And the time it takes to find the source of the bug. It doesn't matter if it's a one-character fix if you have to go through 10 KLOC to find where the problem is.
> For dereferencing null, you can look at the call stack and add contracts to find where null's being passed in. For integer overflows, it's a bit more difficult.

Finding the source of the bug is part of the "trouble it takes to fix it".

Bruno Medeiros - Software Developer, MSc. in CS/E graduate
May 04, 2014
> When a programmer cares for integer overflow one can use Bounded!(T.min, T.max).

See mine extension of Adam's bounded.d:

I call it bound.d instead to save to characters :)

Next ›   Last »
1 2 3