On 9/15/2017 5:00 PM, bitwise wrote:
> On Friday, 15 September 2017 at 21:21:01 UTC, Walter Bright wrote:
>> https://dlang.org/phobos/std_experimental_checkedint.html
> 
> Will this ever be integrated directly into the compiler?

No plans to do so.

On 9/15/2017 9:39 AM, Kagamin wrote:
> It's not because nobody knows about buffer overflows. C leaves the task on the programmer, and the task is too huge for manual labor without help from the language, ecosystem and coding practices, of course nobody does it.

The problem with C is that it isn't mechanically checkable. There's no way to reliably tell if a piece of code is memory safe or not, regardless of how competent the programmer is or how hard he works.

The programming community is coming around, very slowly, to what the airframe industry learned generations ago. I.e. you *never* rely on people in the system not making mistakes.

On 9/16/2017 2:55 AM, Walter Bright wrote:
> The programming community is coming around, very slowly, to what the airframe industry learned generations ago. I.e. you *never* rely on people in the system not making mistakes.

The Equifax disaster is another lesson the airframe industry learned generations ago. Compartmentalization. (Battleships and spy networks learned that centuries ago.)

A single security error in the Equifax system led to losing ALL of their data.

Sensitive data should be compartmentalized, i.e. being spread among systems each with their own security. Access to one compartment does not give access to any other compartments.

On Friday, September 15, 2017 19:01:18 Walter Bright via Digitalmars-d wrote:
> On 9/15/2017 5:00 PM, bitwise wrote:
> > On Friday, 15 September 2017 at 21:21:01 UTC, Walter Bright wrote:
> >> https://dlang.org/phobos/std_experimental_checkedint.html
> >
> > Will this ever be integrated directly into the compiler?
>
> No plans to do so.

There also really isn't a need to do so. If you care about having the overflow checks, then you use Checked. If you don't, you don't. And from what I recall of Andrei's talk on it, Checked is insanely customizable - which a built-in feature wouldn't be.

Personally, I've never had a need for checked ints. I've rarely seen code that would care, and when you do, it's usually pretty easy to deal with it properly. But Checked is there for those who feel the need.

- Jonathan M Davis

On Monday, 18 September 2017 at 08:27:21 UTC, Jonathan M Davis wrote:
> There also really isn't a need to do so.

If there was no need then C/C++ compilers wouldn't provide it as an option…

On Monday, 18 September 2017 at 08:27:21 UTC, Jonathan M Davis wrote:
>
> If you care about having the overflow checks

On Monday, 18 September 2017 at 08:27:21 UTC, Jonathan M Davis wrote:
>
> Personally, I've never had a need for checked ints. I've rarely seen code that would care, and when you do, it's usually pretty easy to deal with it properly. But Checked is there for those who feel the need.

That we don't feel the need or care doesn't mean the problem doesn't exist. That's why I gave an example that I always felt was safe ( malloc(w*h)) but wasn't.

I'd wager no native programmer feel the need for overflow checks or Checked!int, that's why we have security problems in the first place.

On Monday, 18 September 2017 at 08:35:44 UTC, Ola Fosheim Grøstad wrote:
> If there was no need then C/C++ compilers wouldn't provide it as an option…

Do they check unsigned integers?

On 09/15/2017 04:46 AM, Guillaume Piolat wrote:
> As a die-hard native programmer I was always disgusted by integer overflow checks and array bounds checks. Littering code with branches everywhere? Just let me go as fast possible please!
> 
> Last week I was explained by security people how a part of vulnerabilities todays are attacks on image parsers, and how integer overflow checks may help there.
> 
> IIRC a typical attack on image format parser is to forge an image with a width and height that will overflow an int.
> 
> On allocation, the result of the multiplied wraps around like this:
> 
>      int width = parse_width_from_stream();     // eg: 131072
>      int height = parse_height_from_stream();   // eg: 131073
>      ubyte[] data = malloc(width * height * 4); // wraps around, allocates way less memory than that

For the record, with the help of std.experimental.checkedint, the change that fixes the code would be:

malloc(width * height * 4) ==> malloc((checked(width) * height * 4).get)

That aborts the application with a message if a multiplication overflows.


Andrei

On Monday, September 18, 2017 08:35:44 Ola Fosheim Grøstad via Digitalmars-d wrote:
> On Monday, 18 September 2017 at 08:27:21 UTC, Jonathan M Davis
>
> wrote:
> > There also really isn't a need to do so.
>
> If there was no need then C/C++ compilers wouldn't provide it as an option…

We have std.experimental.checkedint, so why would there be any need for it to be in the compiler? The library solution provides the functionality and does so in a much more flexible manner than the compiler reasonably could.

- Jonathan M Davis

On Monday, 18 September 2017 at 14:36:35 UTC, Jonathan M Davis wrote:
> We have std.experimental.checkedint, so why would there be any need for it to be in the compiler? The library solution provides the functionality and does so in a much more flexible manner than the compiler reasonably could.

So that you can use third party libraries?

Or debug your application?