www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - IOC is inside Clang-head

reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Jan 29 2013
next sibling parent "David Nadlinger" <see klickverbot.at> writes:
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
Jan 29 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
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.
Jan 29 2013
prev sibling next sibling parent reply "Don" <don nospam.com> writes:
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.
Jan 29 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 29 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 29 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 29 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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 :-)
Jan 29 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 31 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/31/2013 11:42 AM, Joseph Rushton Wakeling wrote:
 On 01/31/2013 08:15 PM, Walter Bright wrote:
 GC isn't designed to 100% deallocate all unused memory. But C programs
typically
 are.

As you can probably tell, I have absolutely no clue about the rationale behind these differences or their consequences -- could you enlighten me?

It's a large topic for a n.g. posting. May I recommend the classic book on the subject, Garbage Collection by Richard Jones: http://www.amazon.com/exec/obidos/ASIN/0471941484/classicempire (yes, it's an affiliate link)
Jan 31 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-31 23:54, Walter Bright wrote:

 It's a large topic for a n.g. posting. May I recommend the classic book
 on the subject, Garbage Collection by Richard Jones:

 http://www.amazon.com/exec/obidos/ASIN/0471941484/classicempire

This seems to be an update: http://www.amazon.com/The-Garbage-Collection-Handbook-Management/dp/1420082795/ref=pd_bxgy_b_img_y -- /Jacob Carlborg
Jan 31 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2013 12:32 AM, SomeDude wrote:
 My wishlist for a real revision of C would be [...] And nothing more.

I've been seeing those wish lists for 25 years now. The trouble is, everyone has a very different list!
Feb 03 2013
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 03.02.2013 12:10, schrieb Walter Bright:
 On 2/3/2013 12:32 AM, SomeDude wrote:
 My wishlist for a real revision of C would be [...] And nothing more.

I've been seeing those wish lists for 25 years now. The trouble is, everyone has a very different list!

Funny thing is that if we ignore the syntax issues, Turbo Pascal, Modula-2 and Ada had most of those features back in the 80's. What made me eventually move into C++ and only use C level features when required, was the language ability to follow the Pascal family strong typing when one does proper use of high level abstractions the language offers. However C++'s lack of feature scope like D's safe/system/trusted, means without tools is not possible to guarantee a safe code base given the language complexity. -- Paulo
Feb 03 2013
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 03.02.2013 13:53, schrieb SomeDude:
 On Sunday, 3 February 2013 at 11:11:15 UTC, Walter Bright wrote:
 On 2/3/2013 12:32 AM, SomeDude wrote:

It seems to me that the C experts crowd is the most conservative crowd you can find, and one that loves to impose its own masochism to the rest of the world.

+1 :)
Feb 03 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2013 4:53 AM, SomeDude wrote:
 It seems to me that the C experts crowd is the most conservative crowd you can
 find, and one that loves to impose its own masochism to the rest of the world.

I suspect that what happened is the C people who wanted more have long since moved to other languages, and the ones left are the people who don't want C to change at all. Heck, even I proposed a way to fix C's array problem (which is, by far, C's biggest mistake) in a backwards compatible way, and all I get are blank looks from the C people.
Feb 03 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 03.02.2013 20:42, schrieb Walter Bright:
 On 2/3/2013 4:53 AM, SomeDude wrote:
 It seems to me that the C experts crowd is the most conservative crowd
 you can
 find, and one that loves to impose its own masochism to the rest of
 the world.

I suspect that what happened is the C people who wanted more have long since moved to other languages, and the ones left are the people who don't want C to change at all.

One of the few things I like about Windows 8 is that if Microsoft has its way, C will eventually become a second class citizen at least on one major platform.
 Heck, even I proposed a way to fix C's array problem (which is, by far,
 C's biggest mistake) in a backwards compatible way, and all I get are
 blank looks from the C people.

Proper modules, removing array to pointer decay with length support would surely make it a better language.
Feb 03 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2013 10:11 PM, Maxim Fomin wrote:
 Old C programmers are experts in
 some fields and do not follow cool and idiotic ideas in programming languages.

C's design isn't free of mistakes, either.
Feb 03 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/4/2013 12:10 AM, Maxim Fomin wrote:
 On Monday, 4 February 2013 at 07:50:41 UTC, Walter Bright wrote:
 On 2/3/2013 10:11 PM, Maxim Fomin wrote:
 Old C programmers are experts in
 some fields and do not follow cool and idiotic ideas in programming languages.

C's design isn't free of mistakes, either.

That's for sure. And time factor contributed to the gap between how C is evaluated today and how it was evaluated when was established.

I try to look at C's design mistakes in the context of the time when it was created, rather than in today's context which would be unreasonable. For example, despite history showing the preprocessor to be a bad idea, it was a good idea at the time, especially considering the small amount of memory available to the compiler. It enabled a lot of powerful capability for a small amount of compiler technology. A serious design mistake that is understandable but less forgivable is the conflation of arrays and pointers, and I'd argue that is C's worst mistake. C++'s use of < > for template parameters is not forgivable because many people correctly predicted its problems at the time.
Feb 04 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/7/2013 6:52 PM, Ziad Hatahet wrote:
 On Mon, Feb 4, 2013 at 9:38 AM, Walter Bright <newshound2 digitalmars.com
 <mailto:newshound2 digitalmars.com>> wrote:


     C++'s use of < > for template parameters is not forgivable because many
     people correctly predicted its problems at the time.


 Does that also apply to Java and C#? :)

I haven't paid attention to those usages, so I don't have anything informed to say about it.
Feb 07 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/7/2013 8:48 PM, Ziad Hatahet wrote:
 So what was it about C++ that made it a bad choice to use < > for template
 parameters (honest question). Was it because it also overloads the << and >>
 operators?

Grammatical ambiguities which require semantic analysis to figure out, such as: a < b < c >> 3
Feb 07 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/7/13 10:33 PM, Walter Bright wrote:
 On 2/7/2013 6:52 PM, Ziad Hatahet wrote:
 On Mon, Feb 4, 2013 at 9:38 AM, Walter Bright <newshound2 digitalmars.com
 <mailto:newshound2 digitalmars.com>> wrote:


 C++'s use of < > for template parameters is not forgivable because many
 people correctly predicted its problems at the time.


 Does that also apply to Java and C#? :)

I haven't paid attention to those usages, so I don't have anything informed to say about it.

Java and C# don't allow expression template parameters, so < and > are harmless in those languages. However, the choice does lock them out of adding expression parameters later. Andrei
Feb 07 2013
prev sibling parent Jeff Nowakowski <jeff dilacero.org> writes:
On 01/30/2013 07:48 PM, H. S. Teoh wrote:
 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).

The C standard defines sizeof(char) to be 1. By the way, I learned this fact many years ago when reading the book, "C: A Reference Manual", from Harbison and Steele, which I recommend highly for anybody serious about C. It dispelled a lot of mysteries surrounding C for me that were left by other books, and I've used it countless times as a reference.
Feb 01 2013
prev sibling next sibling parent "Thiez" <thiezz gmail.com> writes:
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?
Jan 29 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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 ?
Jan 29 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
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%.
Jan 29 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
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
Jan 29 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
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
Jan 29 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
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
Jan 30 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
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
Jan 30 2013
prev sibling next sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
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!
Jan 30 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Jan 30 2013
prev sibling next sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
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.
Jan 30 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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?
Jan 31 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 01/31/2013 08:15 PM, Walter Bright wrote:
 GC isn't designed to 100% deallocate all unused memory. But C programs
typically
 are.

As you can probably tell, I have absolutely no clue about the rationale behind these differences or their consequences -- could you enlighten me?
Jan 31 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 01/31/2013 11:54 PM, Walter Bright wrote:
 It's a large topic for a n.g. posting. May I recommend the classic book on the
 subject, Garbage Collection by Richard Jones:

Looks very interesting, thank you.
 http://www.amazon.com/exec/obidos/ASIN/0471941484/classicempire

 (yes, it's an affiliate link)

Quite right too. :-)
Jan 31 2013
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
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

My wishlist for a real revision of C would be: - removes anachronisms like those discussed in this thread, - add slightly better safety in the use of const (like in C++), - add C++ style referencess, - and finally add alternative to includes and the preprocessor by the use of modules. And nothing more. Oh, and provide a better/safer standard library: - add {sz, char *} strings to null terminated strings, - add standard structures like vectors, linked list, hashmap, etc, - add abstractions for multithreading Such a revised C could be backward compatible with standard C (with the restriction of said anachronisms) and show exactly the same performance characteristics, while being much more clean. AFAIK, there exists at least one attempt at a compiler which replaces includes by modules.
Feb 03 2013
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 3 February 2013 at 11:11:15 UTC, Walter Bright wrote:
 On 2/3/2013 12:32 AM, SomeDude wrote:
 My wishlist for a real revision of C would be [...] And 
 nothing more.

I've been seeing those wish lists for 25 years now. The trouble is, everyone has a very different list!

And yet C is probably the non obscure language that has evolved the least within these 25 years. Which is all the more astonishing that none of the features in my wishlist is particularly difficult to implement, none of them breaks compatibility with the past, and none of them makes it hard to port to exotic architectures. The last C standard has been particularly disappointing in this regard, as next to nothing that really matters has changed. It seems to me that the C experts crowd is the most conservative crowd you can find, and one that loves to impose its own masochism to the rest of the world.
Feb 03 2013
prev sibling next sibling parent Ziad Hatahet <hatahet gmail.com> writes:
--047d7b66f5159e203c04d4da8496
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Feb 3, 2013 at 1:12 PM, Paulo Pinto <pjmlp progtools.org> wrote:

 One of the few things I like about Windows 8 is that if Microsoft has its
 way, C will eventually become a second class citizen at least on one major
 platform.

Windows though? -- Ziad --047d7b66f5159e203c04d4da8496 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><div class=3D"gmail_quote">On Sun, Feb 3, 2013 at 1:12 PM, Paulo Pinto = <span dir=3D"ltr">&lt;<a href=3D"mailto:pjmlp progtools.org" target=3D"_bla= nk">pjmlp progtools.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex"> One of the few things I like about Windows 8 is that if Microsoft has its w= ay, C will eventually become a second class citizen at least on one major p= latform.<div class=3D"im"><br></div></blockquote><div><br>I presume you mea= n to C++? Since when was C a first class citizen on Windows though? <br> </div><div><br clear=3D"all"><div>--<br>Ziad</div> <br>=A0</div></div><br> --047d7b66f5159e203c04d4da8496--
Feb 03 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Sunday, 3 February 2013 at 12:53:19 UTC, SomeDude wrote:
 It seems to me that the C experts crowd is the most 
 conservative crowd you can find, and one that loves to impose 
 its own masochism to the rest of the world.

Good catch. But I see slightly different way. Old C programmers are experts in some fields and do not follow cool and idiotic ideas in programming languages.
Feb 03 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Monday, 4 February 2013 at 07:50:41 UTC, Walter Bright wrote:
 On 2/3/2013 10:11 PM, Maxim Fomin wrote:
 Old C programmers are experts in
 some fields and do not follow cool and idiotic ideas in 
 programming languages.

C's design isn't free of mistakes, either.

That's for sure. And time factor contributed to the gap between how C is evaluated today and how it was evaluated when was established.
Feb 04 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 3 February 2013 at 23:41:56 UTC, Ziad Hatahet wrote:
 On Sun, Feb 3, 2013 at 1:12 PM, Paulo Pinto 
 <pjmlp progtools.org> wrote:

 One of the few things I like about Windows 8 is that if 
 Microsoft has its
 way, C will eventually become a second class citizen at least 
 on one major
 platform.

citizen on Windows though? -- Ziad

Windows x.y (16 bit), kernel level and games programming ? C++ is gaining again first class status again in Windows 8, now with the WinRT runtime based on COM. On Build 2012 there was a brief mention from Herb Sutter that kernel team is making the C kernel code be compilable in C++ mode. http://channel9.msdn.com/Events/Build/2012/2-005 -- Paulo
Feb 04 2013
prev sibling next sibling parent Ziad Hatahet <hatahet gmail.com> writes:
--047d7b3a7feab5f9f104d52da707
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 4, 2013 at 9:38 AM, Walter Bright <newshound2 digitalmars.com>wrote:

 C++'s use of < > for template parameters is not forgivable because many
 people correctly predicted its problems at the time.

Does that also apply to Java and C#? :) --047d7b3a7feab5f9f104d52da707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Mon, Feb 4, 2013 at 9:38 AM, Walter Bright <s= pan dir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D= "_blank">newshound2 digitalmars.com</a>&gt;</span> wrote:<br><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex"> <br> C++&#39;s use of &lt; &gt; for template parameters is not forgivable becaus= e many people correctly predicted its problems at the time.<br> </blockquote></div><br>Does that also apply to Java and C#? :)<br><br> --047d7b3a7feab5f9f104d52da707--
Feb 07 2013
prev sibling next sibling parent Ziad Hatahet <hatahet gmail.com> writes:
--047d7b3a7feac3d02904d52f4592
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Feb 7, 2013 at 7:33 PM, Walter Bright <newshound2 digitalmars.com>wrote:

 I haven't paid attention to those usages, so I don't have anything
 informed to say about it.

So what was it about C++ that made it a bad choice to use < > for template parameters (honest question). Was it because it also overloads the << and
 operators?


-- Ziad --047d7b3a7feac3d02904d52f4592 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><div class=3D"gmail_quote">On Thu, Feb 7, 2013 at 7:33 PM, Walter Brigh= t <span dir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com" targe= t=3D"_blank">newshound2 digitalmars.com</a>&gt;</span> wrote:<br><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"> <br> I haven&#39;t paid attention to those usages, so I don&#39;t have anything = informed to say about it.<br> </blockquote></div><br><br><br>So what was it about C++ that made it a bad = choice to use &lt; &gt; for template parameters (honest question). Was it b= ecause it also overloads the &lt;&lt; and &gt;&gt; operators?<br><br clear= =3D"all"> <div>--<br>Ziad</div> <br> --047d7b3a7feac3d02904d52f4592--
Feb 07 2013
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 4 February 2013 at 06:11:49 UTC, Maxim Fomin wrote:
 On Sunday, 3 February 2013 at 12:53:19 UTC, SomeDude wrote:
 It seems to me that the C experts crowd is the most 
 conservative crowd you can find, and one that loves to impose 
 its own masochism to the rest of the world.

Good catch. But I see slightly different way. Old C programmers are experts in some fields and do not follow cool and idiotic ideas in programming languages.

Well, even Brian Kernighan said recently: "Avoid the preprocessor".
Feb 09 2013
prev sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 9 February 2013 at 18:47:00 UTC, SomeDude wrote:
 On Monday, 4 February 2013 at 06:11:49 UTC, Maxim Fomin wrote:
 On Sunday, 3 February 2013 at 12:53:19 UTC, SomeDude wrote:
 It seems to me that the C experts crowd is the most 
 conservative crowd you can find, and one that loves to impose 
 its own masochism to the rest of the world.

Good catch. But I see slightly different way. Old C programmers are experts in some fields and do not follow cool and idiotic ideas in programming languages.

Well, even Brian Kernighan said recently: "Avoid the preprocessor".

Correction to the above, he said: "avoid macros"
Feb 09 2013