Am 15.04.2014 13:05, schrieb bearophile:
> Paulo Pinto:
>
>> Except, as far as I am aware, they only work on GNU/Linux and Mac OS
>> X, leaving out all other operating systems out there.
>
> Is "-fsanitize=integer" not available in the Windows version of Clang?
>
> Perhaps it's a good idea to create something similar to the sanitizers
> (the memory one, etc) that work on all D compilers.
>
> Bye,
> bearophile

I had the idea that they require some kind of OS MMU API support, which neither Windows, nor commercial UNIX or embedded OS offer.

Maybe I am wrong as I just saw some LLVM presentations about it and currently only code C++ occasionally so I don't follow everything in C++ world.

--
Paulo

On Tuesday, 15 April 2014 at 17:40:13 UTC, Walter Bright wrote:
> On 4/15/2014 10:26 AM, bearophile wrote:
>> Walter Bright:
>>
>>> That's what @safe is for.
>>
>> I think those sanitizers (but the integer-related one) are meant to help D
>> programmers catch bugs in @system code.
>
> I understand that. I've written my own sanitizers in the past and used them heavily. The big advantage of @safe is that it offers a guarantee, sanitizers do not.
>
> Very little, however, of even a hardcore app needs to be @system. What little remains is often @system for performance reasons, where you'd turn off a sanitizer anyway.
>
> To sum up, a sanitizer for D offers little incremental benefit, and has a substantial implementation cost. Such cost would take away from other improvements to D that would be far more valuable.

I agree about implementation cost, and I didn't have enough skills to do it.
I think @safe just a guide or helper, it doesn't offer a guarantee,
because phobos and druntime use a lot of pointer, but less test with them (or didn't release?).

Also we need pointer because many library, kernel of windows/linux/bsd, communication api from outer device is written in c/c++.
Free from pointer is a good dream although it is unrealistic.

Thanks that valgrind can use with d, so it's the only choise now.

Walter Bright:

> What little remains is often @system for performance reasons, where you'd turn off a sanitizer anyway.

You are wrong. Both integer overflow sanitizers and those various modern memory/address sanitizers are not meant to be used in the final release of the code. They are meant to be used one at a time during testing or debugging (and the memory sanitizers slow down the code 2-3 times, so they can be used in many cases of debugging), and then later disabled.

Bye,
bearophile

Walter Bright:

> Such cost would take away from other improvements to D that
> would be far more valuable.

But I agree with this. In this moment there are more important things to do (like finishing synchronized, scope, SIMD, vector operations, operator
overloading, dynamic libraries, GC, and more).

Bye,
bearophile