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 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 "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
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 "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
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 "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 reply "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
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 reply "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
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 "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
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 parent reply "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
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 parent reply "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
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 reply 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
parent reply Ziad Hatahet <hatahet gmail.com> writes:
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.


I presume you mean to C++? Since when was C a first class citizen on
Windows though?

--
Ziad
Feb 03 2013
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.


 I presume you mean to C++? Since when was C a first class 
 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 parent reply "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
next 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 "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
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 Ziad Hatahet <hatahet gmail.com> writes:
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.
Feb 07 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.





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 reply Ziad Hatahet <hatahet gmail.com> writes:
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
Feb 07 2013
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.





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



harmless in those languages. However, the choice does lock them out of 
adding expression parameters later.

Andrei
Feb 07 2013
prev sibling parent reply "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
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
prev sibling parent reply 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
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 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
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
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 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 "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
parent reply "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
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 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