The quality of a language also comes from its compiler. Clang 3.3 will have this inside:

http://embed.cs.utah.edu/ioc/

To use it you have to compile with "-fsanitize=integer":

http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation

It slows down the code, but it's optional, it's meant mostly to debug programs, where some slowdown of the program is acceptable.

GCC is not coping with Clang development speed.

Is is possible to use ioc from LDC2? D language should enjoy all the nice things they keep adding to LLVM, otherwise C++ risks becoming more modern than D.

Bye,
bearophile

On Tuesday, 29 January 2013 at 12:26:10 UTC, bearophile wrote:
> Is is possible to use ioc from LDC2? D language should enjoy all the nice things they keep adding to LLVM, otherwise C++ risks becoming more modern than D.

Join LDC development and find it out. ;)

On a more serious note, the IOC patch appears to modify the Clang front-end only, so there is no immediate way to re-use the code for LDC. Taking it as a model to implement a similar code gen switch would certainly seem possible, though.

David

On Tuesday, 29 January 2013 at 12:26:10 UTC, bearophile wrote:
> The quality of a language also comes from its compiler. Clang 3.3 will have this inside:
>
> http://embed.cs.utah.edu/ioc/
>
> To use it you have to compile with "-fsanitize=integer":
>
> http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation
>
> It slows down the code, but it's optional, it's meant mostly to debug programs, where some slowdown of the program is acceptable.
>
> GCC is not coping with Clang development speed.
>
> Is is possible to use ioc from LDC2? D language should enjoy all the nice things they keep adding to LLVM, otherwise C++ risks becoming more modern than D.
>
> Bye,
> bearophile

Oh well there goes my argumentation for security exploits in C.

On Tuesday, 29 January 2013 at 12:26:10 UTC, bearophile wrote:
> The quality of a language also comes from its compiler. Clang 3.3 will have this inside:
>
> http://embed.cs.utah.edu/ioc/
>
> To use it you have to compile with "-fsanitize=integer":
>
> http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation
>
> It slows down the code, but it's optional, it's meant mostly to debug programs, where some slowdown of the program is acceptable.
>
> GCC is not coping with Clang development speed.
>
> Is is possible to use ioc from LDC2? D language should enjoy all the nice things they keep adding to LLVM, otherwise C++ risks becoming more modern than D.

Please stop posting on this topic! I know it is one of your hobby horses, but frankly, it seems to be a topic you do not understand it at all.

Did you even read that page?

"To help developers detect integer overflows, we created IOC (by modifying Clang) to dynamically detect most of C/C++'s integer undefined behaviors. "

The key phrase is *undefined behaviors*. Remember that C does not require twos-complement arithmetic. D does, so it doesn't have those problems in the first place.

It must have been a dozen times by now that you have posted the same misinformation over and over again, with links to papers you have apparently not read.

On Tuesday, 29 January 2013 at 14:22:06 UTC, Don wrote:
> The key phrase is *undefined behaviors*. Remember that C does not require twos-complement arithmetic. D does, so it doesn't have those problems in the first place.
>
> It must have been a dozen times by now that you have posted the same misinformation over and over again, with links to papers you have apparently not read.

So D has no undefined integer behavior at all? Doesn't that waste many opportunities for optimization?

On 1/29/13 11:05 AM, Thiez wrote:
> On Tuesday, 29 January 2013 at 14:22:06 UTC, Don wrote:
>> The key phrase is *undefined behaviors*. Remember that C does not
>> require twos-complement arithmetic. D does, so it doesn't have those
>> problems in the first place.
>>
>> It must have been a dozen times by now that you have posted the same
>> misinformation over and over again, with links to papers you have
>> apparently not read.
>
> So D has no undefined integer behavior at all? Doesn't that waste many
> opportunities for optimization?

It would be quite problematic for a non-twos-complement architecture to emulate D.

Andrei

On Tuesday, 29 January 2013 at 16:42:49 UTC, Andrei Alexandrescu wrote:
> On 1/29/13 11:05 AM, Thiez wrote:
>> On Tuesday, 29 January 2013 at 14:22:06 UTC, Don wrote:
>>> The key phrase is *undefined behaviors*. Remember that C does not
>>> require twos-complement arithmetic. D does, so it doesn't have those
>>> problems in the first place.
>>>
>>> It must have been a dozen times by now that you have posted the same
>>> misinformation over and over again, with links to papers you have
>>> apparently not read.
>>
>> So D has no undefined integer behavior at all? Doesn't that waste many
>> opportunities for optimization?
>
> It would be quite problematic for a non-twos-complement architecture to emulate D.
>

Is that a practical limitation ? All widespread arch I know assembly for are 2 complement, and it seems like something settled now in the field. Or am I unaware of some important stuff ?

On 1/29/2013 8:48 AM, deadalnix wrote:
> Is that a practical limitation ? All widespread arch I know assembly for are 2
> complement, and it seems like something settled now in the field. Or am I
> unaware of some important stuff ?

One's complement machines existed when I was a wee laddie, but I haven't heard of any since.

C (and C++) also "support" things like bytes that are larger than 8 bits. Yes, there are >8 bit byte CPUs in the form of specialized DSP processors, and yes, there are C compilers for them.

But I can't think of a single non-trivial C program that could be compiled for greater than 8 bit bytes without extensive refactoring, so having Standard C "support" such is mostly an exercise in theater and is useless in real life.

Even worse is all the millions of man-hours wasted in (usually incorrectly) trying to make C code portable to theoretical C compilers that have ints larger than 32 bits, etc., trying to ensure that modern C code will work on a 16 bit C compiler, and on and on.

By defining these problems out of existence, D achieves a major simplification in terms of programming bugs that are far more theoretical than real.

One real issue is order of evaluation bugs, but I didn't see a note about that in the Clang list.

On Tuesday, 29 January 2013 at 19:21:34 UTC, Walter Bright wrote:
> On 1/29/2013 8:48 AM, deadalnix wrote:
>> Is that a practical limitation ? All widespread arch I know assembly for are 2
>> complement, and it seems like something settled now in the field. Or am I
>> unaware of some important stuff ?
>
> One's complement machines existed when I was a wee laddie, but I haven't heard of any since.
>
> C (and C++) also "support" things like bytes that are larger than 8 bits. Yes, there are >8 bit byte CPUs in the form of specialized DSP processors, and yes, there are C compilers for them.
>
> But I can't think of a single non-trivial C program that could be compiled for greater than 8 bit bytes without extensive refactoring, so having Standard C "support" such is mostly an exercise in theater and is useless in real life.
>
> Even worse is all the millions of man-hours wasted in (usually incorrectly) trying to make C code portable to theoretical C compilers that have ints larger than 32 bits, etc., trying to ensure that modern C code will work on a 16 bit C compiler, and on and on.

Fully agree here. C support such things for sake of greater portability, however I consider that such support really hurts portability, than enhances it.

> By defining these problems out of existence, D achieves a major simplification in terms of programming bugs that are far more theoretical than real.
>
> One real issue is order of evaluation bugs, but I didn't see a note about that in the Clang list.

After experiencing with C and before joining D, I came to the same conclusion - a new language should reconsider attitude to portability in a sense that it should not support 1% and damaging 99%.

On Tuesday, 29 January 2013 at 19:21:34 UTC, Walter Bright wrote:
> One real issue is order of evaluation bugs, but I didn't see a note about that in the Clang list.

Why would you need runtime checking for that?

Besides the AddressSanatizer and MemorySanatizer features which are obviously real-world oriented (cf. Valgrind), I also find quite a few of the ubsan features to be actually useful in practice - integer overflow detection is only a small part of it.

There was a talk at the last LLVM conference giving an overview of the different "sanatizer" projects: http://llvm.org/devmtg/2012-11/

David