On 1/29/2013 1:15 PM, David Nadlinger wrote:
> 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?

I didn't say you did!


> 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.

valgrind is immensely useful for C, but a lot less so for D as D guarantees initialization and a GC takes care of much of the rest.

On Tuesday, 29 January 2013 at 21:26:11 UTC, Walter Bright wrote:
> On 1/29/2013 1:15 PM, David Nadlinger wrote:
>> 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?
>
> I didn't say you did!

Oh, I assumed that by "the Clang list" you were referring to the docs of the -fsanatize switch, which specifically governs runtime checks.

David

On 1/29/2013 2:04 PM, David Nadlinger wrote:
> On Tuesday, 29 January 2013 at 21:26:11 UTC, Walter Bright wrote:
>> On 1/29/2013 1:15 PM, David Nadlinger wrote:
>>> 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?
>>
>> I didn't say you did!
>
> Oh, I assumed that by "the Clang list" you were referring to the docs of the
> -fsanatize switch, which specifically governs runtime checks.

I thought they included compile time ones. My bad.

(And I keep reading -fsanatize as -fantasize :-)

On Tuesday, 29 January 2013 at 21:26:11 UTC, Walter Bright wrote:
> On 1/29/2013 1:15 PM, David Nadlinger wrote:
>> 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?
>
> I didn't say you did!
>
>
>> 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.
>
> valgrind is immensely useful for C, but a lot less so for D as D guarantees initialization and a GC takes care of much of the rest.

Many have jokes about Java being a language that requires an IDE to be usable.

Usually I joke that C is a language for tool vendors. How many vendors can take their business to C undefined behaviors and pointer abuse.

No one on their senses does use C today without an endless list of tools that validate their code is not going to explode.

--
Paulo

On Wednesday, 30 January 2013 at 09:01:53 UTC, Paulo Pinto wrote:
> On Tuesday, 29 January 2013 at 21:26:11 UTC, Walter Bright wrote:
>> On 1/29/2013 1:15 PM, David Nadlinger wrote:
>>> 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?
>>
>> I didn't say you did!
>>
>>
>>> 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.
>>
>> valgrind is immensely useful for C, but a lot less so for D as D guarantees initialization and a GC takes care of much of the rest.
>
> Many have jokes about Java being a language that requires an IDE to be usable.
>
> Usually I joke that C is a language for tool vendors. How many vendors can take their business to C undefined behaviors and pointer abuse.
>
> No one on their senses does use C today without an endless list of tools that validate their code is not going to explode.
>
> --
> Paulo

s/take/thank

On Tuesday, 29 January 2013 at 19:21:34 UTC, Walter Bright wrote:
> 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.

You know, defining a problem out of existence is a damn good way of solving the problem!

On Thu, Jan 31, 2013 at 01:36:06AM +0100, Zach the Mystic wrote:
> On Tuesday, 29 January 2013 at 19:21:34 UTC, Walter Bright wrote:
> >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.
> 
> You know, defining a problem out of existence is a damn good way of solving the problem!

The point was that these problems are by and large non-problems. Even where these issues are applicable, people are already not using stock C compilers anyway, so it's pointless to address them in the general case.

If you're somewhat familiar with the details of the C standard, you'll realize that a laughably large percentage of C code currently in use is actually invalid C (either due to undefined behaviour, or incorrect reliance on sizeof(char)==1, or a whole bunch of other obscure rules that most C programmers aren't even aware of). Even some of the most portable C code out there is actually non-portable according to the standard.


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley

On Thursday, 31 January 2013 at 00:50:39 UTC, H. S. Teoh wrote:
> On Thu, Jan 31, 2013 at 01:36:06AM +0100, Zach the Mystic wrote:
>> On Tuesday, 29 January 2013 at 19:21:34 UTC, Walter Bright wrote:
>> >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.
>> 
>> You know, defining a problem out of existence is a damn good way of
>> solving the problem!
>
> The point was that these problems are by and large non-problems. Even
> where these issues are applicable, people are already not using stock C
> compilers anyway, so it's pointless to address them in the general case.
>
> If you're somewhat familiar with the details of the C standard, you'll
> realize that a laughably large percentage of C code currently in use is
> actually invalid C (either due to undefined behaviour, or incorrect
> reliance on sizeof(char)==1, or a whole bunch of other obscure rules
> that most C programmers aren't even aware of). Even some of the most
> portable C code out there is actually non-portable according to the
> standard.
>
>
> T

Well, I suppose only a tiny fraction of all programming problems fall into the category where it becomes possible to define them out of existence. But it's definitely the way to go, I'd say, if it's one of the available choices. At the same time, it probably takes good sense to actually recognize both that it is a choice and to go ahead and make that choice. I meant the comment as both a joke and a compliment with regards to that good sense.

On 01/29/2013 10:26 PM, Walter Bright wrote:
> valgrind is immensely useful for C, but a lot less so for D as D guarantees
> initialization and a GC takes care of much of the rest.

On the subject of valgrind and D's garbage collection -- when I've run any D program through valgrind's memory check, it always reports a small amount of memory that has failed to deallocate at the end of the program (IIRC it's about 3 allocs that valgrind thinks have not been deallocated).

Is there any particular reason why this should be so?  Is it an error in D or in valgrind's tracking of D's memory management?

On 1/31/2013 7:27 AM, Joseph Rushton Wakeling wrote:
> On 01/29/2013 10:26 PM, Walter Bright wrote:
>> valgrind is immensely useful for C, but a lot less so for D as D guarantees
>> initialization and a GC takes care of much of the rest.
>
> On the subject of valgrind and D's garbage collection -- when I've run any D
> program through valgrind's memory check, it always reports a small amount of
> memory that has failed to deallocate at the end of the program (IIRC it's about
> 3 allocs that valgrind thinks have not been deallocated).
>
> Is there any particular reason why this should be so?  Is it an error in D or in
> valgrind's tracking of D's memory management?

GC isn't designed to 100% deallocate all unused memory. But C programs typically are.