www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Heartbleed and static analysis

reply "bearophile" <bearophileHUGS lycos.com> writes:
A nice blog post, about the Coverity scan not finding the 
Heartbleed (http://heartbleed.com/) bug:

http://blog.regehr.org/archives/1125

Bye,
bearophile
Apr 11 2014
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 11 April 2014 at 09:47:14 UTC, bearophile wrote:
 A nice blog post, about the Coverity scan not finding the 
 Heartbleed (http://heartbleed.com/) bug:

 http://blog.regehr.org/archives/1125

 Bye,
 bearophile

In a way it's scary how vulnerable software we rely on still is. I cannot claim that my software is immune to attacks, but where security is crucial, one would expect self-critical scrutiny rather than complacency. But we're all only human.
Apr 11 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 13.04.2014 00:10, schrieb froglegs:
   Why do they write such important code in C to begin with? C is garbage
 compared to C++.  With C++ they wouldn't need to drop down to raw
 pointers and would never have these problems.

 (of course D guys will say use D, but lets be real, D isn't ready for
 many obvious reasons)

As much as I love to hate C, it won't go away that easily: - Being married with UNIX and its culture; - Except for Windows, Android hybrid and RTOS, UNIX is everywhere nowadays - The macho attitude that pertains C culture that programmers make no errors This is one of those things that only will go away with a few generations, but even the newer generations will need to maintain running UNIX systems, thus the circle of doom keeps turning around. -- Paulo
Apr 13 2014
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 13.04.2014 00:38, schrieb H. S. Teoh:
 On Sat, Apr 12, 2014 at 10:10:55PM +0000, froglegs wrote:
   Why do they write such important code in C to begin with? C is
 garbage compared to C++.  With C++ they wouldn't need to drop down to
 raw pointers and would never have these problems.

If you were to ask me 5-10 years ago which language was better, I'd say C++. Today, I'm not so sure anymore. Both suck. And I'm not sure which one sucks more -- 5 years ago I'd say C, but now I'm leaning towards saying C++. ...

20 years ago I would have answered both are bad and Object Pascal/Delphi is the way. Sadly Borland did lots of major screw ups and let the language momentum fade away. C++ provides safer ways to code than C, but it requires competent programmers. However both C and C++ require competent programmers above what the market is willing to pay, and on my area switching to C doesn't help improve the quality. Every now and then, I feel nostalgic of not writing C++ or even with my prejudices C code at work, but then I look at the quality of code that gets written in our outsourcing projects and get a relief not having to go back into that world. -- Paulo
Apr 13 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/13/2014 5:57 AM, Dicebot wrote:
 Ironically, I have been using Pascal/Delphi at my first programming job.
 Switching later to C was a big relief - yes, it was less safe and sometimes
 awkward. But it did feel like a language designed by engineers, not
academicians
 and that alone has boosted productivity a lot.

I had the same feeling switching from Pascal to C. I was far more productive in C right off the bat. I never looked back, never wrote another line of Pascal.
Apr 13 2014
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 13.04.2014 14:57, schrieb Dicebot:
 On Sunday, 13 April 2014 at 08:55:47 UTC, Paulo Pinto wrote:
 20 years ago I would have answered both are bad and Object
 Pascal/Delphi is the way.

 Sadly Borland did lots of major screw ups and let the language
 momentum fade away.

Ironically, I have been using Pascal/Delphi at my first programming job. Switching later to C was a big relief - yes, it was less safe and sometimes awkward. But it did feel like a language designed by engineers, not academicians and that alone has boosted productivity a lot.

Different experiences I guess. I never felt C made me productive in any way.
Apr 13 2014
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2014-04-13 08:55:53 +0000, "Paolo Invernizzi" 
<paolo.invernizzi no.address> said:

 I don't remember if this has been already posted here in the forum, but 
 I think that this rant of Theo de Raadt about heartbleed is _very_ 
 interesting.
 
 http://article.gmane.org/gmane.os.openbsd.misc/211963
 
 TBW, I agree with him: it's not a matter of scrutiny or a matter of 
 being human, and the post clarify this very well.

Interesting. As far as I know, the D GC is also a wrapper around malloc, and it will not return memory using free when an object is deallocated. That rant could also apply to D. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Apr 13 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/13/2014 4:04 AM, Michel Fortin wrote:
 Interesting. As far as I know, the D GC is also a wrapper around malloc, and it
 will not return memory using free when an object is deallocated. That rant
could
 also apply to D.

You're right in that a malloc debugger would be ineffective when the D GC is used. But the D GC offers its own memory debugging features. They can be turned on with version identifiers in the GC source.
Apr 13 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/13/2014 9:26 AM, Dicebot wrote:
 C++ fault is that it makes very easy even for experienced programmer to write
 faulty code and consequences of a mistake can be rather dire. C has similar
 issues but C is much smaller and simpler language which allows to keep all
 possible danger points in mind. I have yet to meet a single C++ programmer who
 can remember about all corner cases at the same time. I am not sure even Bjorne
 himself can.

 D makes situation much better by refining base semantics to adhere "safe by
 default, fast when explicitly asked" principle (array bounds checks, default
 initialization of locals). It is still not 100% consistent but greatly reduces
 stress of the context comparing to C++.

 I'd still prefer C++ over C for most projects but only if using very small
 well-defined  subset of C++ verified by static analysis tool continuously.

Interestingly, I've been seeing that what makes D code much more robust is a consequence of 'unittest' coupled with -cov.
Apr 13 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/13/2014 10:38 AM, Dicebot wrote:
 I think most important thing about built-in unittests is how this feature
 encourages to add tests when contributing to projects that don't currently have
 any real coverage. It becomes so easy that there is not reason to not do it and
 this help open-source a lot.

Exactly. You can do unittests with other languages, too, but having it be so convenient, and no arguments about which unittest tool, is a game changer. The built-in -cov is also a game changer.
Apr 13 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 13.04.2014 20:40, schrieb Walter Bright:
 On 4/13/2014 10:38 AM, Dicebot wrote:
 I think most important thing about built-in unittests is how this feature
 encourages to add tests when contributing to projects that don't
 currently have
 any real coverage. It becomes so easy that there is not reason to not
 do it and
 this help open-source a lot.

Exactly. You can do unittests with other languages, too, but having it be so convenient, and no arguments about which unittest tool, is a game changer. The built-in -cov is also a game changer.

Until one gets lousy management in the picture. :( Sorry, just got a lousy week with developers deleting unit tests to "improve" their builds. -- Paulo
Apr 13 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 13/04/14 20:40, Walter Bright wrote:

 Exactly. You can do unittests with other languages, too, but having it
 be so convenient, and no arguments about which unittest tool, is a game
 changer. The built-in -cov is also a game changer.

The built-in unittest functionality is too limited. One needs some framework built on top of it. Then you get back to the arguments about which framework to use. -- /Jacob Carlborg
Apr 14 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/11/2014 2:47 AM, bearophile wrote:
 A nice blog post, about the Coverity scan not finding the Heartbleed
 (http://heartbleed.com/) bug:

 http://blog.regehr.org/archives/1125

http://www.reddit.com/r/programming/comments/22ri2i/heartbleed_wasnt_found_by_static_analysis/
Apr 11 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 11.04.2014 16:00, schrieb bearophile:
 Paulo Pinto:

 The idea was that developers would use lint for such purposes, what
 very few do, even in 2014.

Such moderate static analysis needs to be part of the default work of the language compiler. Bye, bearophile

Fully agree, Paulo
Apr 11 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/11/2014 4:36 AM, Paulo Pinto wrote:
 This will never change as we (me and Walter) discussed on a parallel thread.

 The way arrays decay into pointers cannot be fixed while keeping backwards
 compatibility.

 Algol, PL/I and Mesa had bounds checked arrays, with the option to disable them
 if required, but C designers decided against it.

 The idea was that developers would use lint for such purposes, what very few
do,
 even in 2014.

 I am convinced that this will only get fixed by a generation change.

The change I suggest is purely additive, meaning it will not break any existing code. If C can add VLAs, it can add this. I have talked about this change with C people a few years ago, and I just kinda got a blank look in return. Maybe, though, C people will finally get fed up with these sorts of avoidable problems.
Apr 11 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/11/2014 1:54 PM, bearophile wrote:
 Lot of the world computational infrastructure is based on C code,
 so you can't just ignore their problems. If the C community is
 not willing to improve, then people outside their culture have to
 force them to change (because rewriting that code in another
 language is often too much work).

That's why I offered a simple enhancement to C in the article.
Apr 11 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 11 April 2014 at 10:09:48 UTC, Walter Bright wrote:
 On 4/11/2014 2:47 AM, bearophile wrote:
 A nice blog post, about the Coverity scan not finding the 
 Heartbleed
 (http://heartbleed.com/) bug:

 http://blog.regehr.org/archives/1125

http://www.reddit.com/r/programming/comments/22ri2i/heartbleed_wasnt_found_by_static_analysis/

So why don't you just write your own language? Uh, wait, you did just that. Is there any chance that these issues will be fixed in C some day, or is it too late, or is the C consortium too narrow-minded, stubborn, indifferent?
Apr 11 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 11 April 2014 at 10:33:52 UTC, Chris wrote:
 On Friday, 11 April 2014 at 10:09:48 UTC, Walter Bright wrote:
 On 4/11/2014 2:47 AM, bearophile wrote:
 A nice blog post, about the Coverity scan not finding the 
 Heartbleed
 (http://heartbleed.com/) bug:

 http://blog.regehr.org/archives/1125

http://www.reddit.com/r/programming/comments/22ri2i/heartbleed_wasnt_found_by_static_analysis/

So why don't you just write your own language? Uh, wait, you did just that. Is there any chance that these issues will be fixed in C some day, or is it too late, or is the C consortium too narrow-minded, stubborn, indifferent?

This will never change as we (me and Walter) discussed on a parallel thread. The way arrays decay into pointers cannot be fixed while keeping backwards compatibility. Algol, PL/I and Mesa had bounds checked arrays, with the option to disable them if required, but C designers decided against it. The idea was that developers would use lint for such purposes, what very few do, even in 2014. I am convinced that this will only get fixed by a generation change. -- Paulo
Apr 11 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Paulo Pinto:

 The idea was that developers would use lint for such purposes, 
 what very few do, even in 2014.

Such moderate static analysis needs to be part of the default work of the language compiler. Bye, bearophile
Apr 11 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Maybe, though, C people will finally get fed up with these
 sorts of avoidable problems.

Lot of the world computational infrastructure is based on C code, so you can't just ignore their problems. If the C community is not willing to improve, then people outside their culture have to force them to change (because rewriting that code in another language is often too much work). Bye, bearophile
Apr 11 2014
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 11 Apr 2014 09:59:45 +0000
schrieb "Chris" <wendlec tcd.ie>:

 In a way it's scary how vulnerable software we rely on still is. 
 I cannot claim that my software is immune to attacks, but where 
 security is crucial, one would expect self-critical scrutiny 
 rather than complacency. But we're all only human.

+1. My naive assumption was that something like SSH is implemented once and then bugs are fixed, so it can only ever become safer. I found it astounding that this library was totally sane only 2 years ago. One innocent commit is all it took and it can happen again for any software, any time. If crackers keep their eyes open they _will_ find their next backdoor. -- Marco
Apr 12 2014
prev sibling next sibling parent "froglegs" <nono yahoo.com> writes:
  Why do they write such important code in C to begin with? C is 
garbage compared to C++.  With C++ they wouldn't need to drop 
down to raw pointers and would never have these problems.

(of course D guys will say use D, but lets be real, D isn't ready 
for many obvious reasons)
Apr 12 2014
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Apr 12, 2014 at 10:10:55PM +0000, froglegs wrote:
  Why do they write such important code in C to begin with? C is
 garbage compared to C++.  With C++ they wouldn't need to drop down to
 raw pointers and would never have these problems.

C++ is better in theory, but not all that much better than C in practice. The design flaws of the language often makes it worse than C in terms of maintainability. At my day job, we switched a major project from C++ back to C, because the C++ codebase was over-engineered and full of abstractions that nobody understood, patched over multiple times by people who were reassigned to take the place of the original people who left, who didn't understand the original design but had unreasonable deadlines to meet, so as a result they just added hacks and workarounds to get their job done before they got fired. By the time a few years had passed, *nobody* understood what the system even does, and every new code change was a "blindly copy-n-paste from other parts of the code and pray it won't break something else" deal. It was bloated, slow, and riddled with bugs nobody dared to fix, because nobody understood what it does. Certain features were dependent on dtor side-effects, and other such pathological things, and it was maintenance hell. We rewrote the entire thing in C and, in spite of all C's flaws, at least you didn't have dtors performing magic behind your back and class abstractions that nobody understood what it actually does at runtime. I have to say that, in spite of C's shortcomings, at least it was a (relatively) small and self-contained design, and the gotchas were well understood and well-documented, whereas C++ is a monstrous beast full of every pitfall imaginable. Just about every other line of code you write out of habit is almost guaranteed to be wrong in *some* obscure corner case that only 2% of C++ programmers are even aware of. And in a large team project, you can guarantee that *someone* one day will write code that will trigger exactly that one obscure case that will produce a bug nobody can find. In C, when you mess up, most of the time you get a straight segfault, and you have no choice but to fix it before you check in. Well, most of the time, anyway. The same old off-by-1 buffer overrun bugs just keep recurring and recurring -- I just found another yet a few days ago, which has been lurking in there for a *long* time. Probably years. Sigh... But at least it's a well-known and well-understood problem, whereas in C++ it could be any one of 1000 novel combinations of several obscure C++ spec corner cases that interact in complex ways to produce a bug that most mid-level coders don't even understand, let alone have any idea how to debug. If you were to ask me 5-10 years ago which language was better, I'd say C++. Today, I'm not so sure anymore. Both suck. And I'm not sure which one sucks more -- 5 years ago I'd say C, but now I'm leaning towards saying C++. Now if we can only iron out the last 5% of D's wrinkles, it would be a HUGE relief from C/C++ nastiness. (Unfortunately, Pareto's principle dictates that this last 5% is gonna take us 95% of the time. :-P) T -- "640K ought to be enough" -- Bill G., 1984. "The Internet is not a primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on Microsoft's strategy" -- Bill G., 1999.
Apr 12 2014
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Saturday, 12 April 2014 at 22:40:32 UTC, H. S. Teoh wrote:
 Now if we can only iron out the last 5% of D's wrinkles, it 
 would be a
 HUGE relief from C/C++ nastiness.  (Unfortunately, Pareto's 
 principle
 dictates that this last 5% is gonna take us 95% of the time. 
 :-P)


 T

You mean the first 10 (or 13?) years was only the first 5%? I feel tired.
Apr 12 2014
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Apr 12, 2014 at 11:03:35PM +0000, Meta wrote:
 On Saturday, 12 April 2014 at 22:40:32 UTC, H. S. Teoh wrote:
Now if we can only iron out the last 5% of D's wrinkles, it would be
a HUGE relief from C/C++ nastiness.  (Unfortunately, Pareto's
principle dictates that this last 5% is gonna take us 95% of the
time. :-P)


T

You mean the first 10 (or 13?) years was only the first 5%? I feel tired.

No, the first 10 years was the first 95%. But the last 5% will take the next ... 90 years??? Oh dear. Hopefully we get our act together before then. LONG before then! :-P T -- We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the Internet, we know this is not true. -- Robert Wilensk
Apr 12 2014
prev sibling next sibling parent "froglegs" <nono yahoo.com> writes:
  Teoh--

  Some C++ code bases get that way. I once worked on a codebase 
that was originally C, then added C with classes, and then had 
C++ metaprogramming bolted on top(custom and incomplete 
implementations of half of boost, including MPL).
   While it wasn't the best, I personally did not have a huge 
issue with understanding it. My coworkers, on the other hand, had 
serious problems understanding the metaprogramming, so I always 
had to deal with that code(I did not write it).
  If I could come onto the project and understand it, is it really 
the fault of the language, or the fault of my coworkers for not 
taking it upon themselves to become informed?

  Design flaws of C++? It may have a few, but compared to C? I 
think C++ is far better designed, and far safer.

  A legit flaw I would label C++ with(aside from missing features 
such as modules etc.) is a degree of unnecessary complexity, 
mostly caused by its evolving design. That is just what happens 
when you have a 30 year old language, that is mostly backwards 
compatible with an even older language.

  Because C++ is more complex it requires more informed 
programmers to operate than C.

  If you have a team of informed C++ programmers I feel that it is 
very possible to produce very quickly, high quality reliable 
code. That all members can understand(I'd be inclined to say fire 
anyone that can't grok it, they will just be a liability).

  But anyway I do not understand why important software is still 
written in C. It makes me sad:(




On Saturday, 12 April 2014 at 22:40:32 UTC, H. S. Teoh wrote:
 On Sat, Apr 12, 2014 at 10:10:55PM +0000, froglegs wrote:
  Why do they write such important code in C to begin with? C is
 garbage compared to C++.  With C++ they wouldn't need to drop 
 down to
 raw pointers and would never have these problems.

C++ is better in theory, but not all that much better than C in practice. The design flaws of the language often makes it worse than C in terms of maintainability. At my day job, we switched a major project from C++ back to C, because the C++ codebase was over-engineered and full of abstractions that nobody understood, patched over multiple times by people who were reassigned to take the place of the original people who left, who didn't understand the original design but had unreasonable deadlines to meet, so as a result they just added hacks and workarounds to get their job done before they got fired. By the time a few years had passed, *nobody* understood what the system even does, and every new code change was a "blindly copy-n-paste from other parts of the code and pray it won't break something else" deal. It was bloated, slow, and riddled with bugs nobody dared to fix, because nobody understood what it does. Certain features were dependent on dtor side-effects, and other such pathological things, and it was maintenance hell. We rewrote the entire thing in C and, in spite of all C's flaws, at least you didn't have dtors performing magic behind your back and class abstractions that nobody understood what it actually does at runtime. I have to say that, in spite of C's shortcomings, at least it was a (relatively) small and self-contained design, and the gotchas were well understood and well-documented, whereas C++ is a monstrous beast full of every pitfall imaginable. Just about every other line of code you write out of habit is almost guaranteed to be wrong in *some* obscure corner case that only 2% of C++ programmers are even aware of. And in a large team project, you can guarantee that *someone* one day will write code that will trigger exactly that one obscure case that will produce a bug nobody can find. In C, when you mess up, most of the time you get a straight segfault, and you have no choice but to fix it before you check in. Well, most of the time, anyway. The same old off-by-1 buffer overrun bugs just keep recurring and recurring -- I just found another yet a few days ago, which has been lurking in there for a *long* time. Probably years. Sigh... But at least it's a well-known and well-understood problem, whereas in C++ it could be any one of 1000 novel combinations of several obscure C++ spec corner cases that interact in complex ways to produce a bug that most mid-level coders don't even understand, let alone have any idea how to debug. If you were to ask me 5-10 years ago which language was better, I'd say C++. Today, I'm not so sure anymore. Both suck. And I'm not sure which one sucks more -- 5 years ago I'd say C, but now I'm leaning towards saying C++. Now if we can only iron out the last 5% of D's wrinkles, it would be a HUGE relief from C/C++ nastiness. (Unfortunately, Pareto's principle dictates that this last 5% is gonna take us 95% of the time. :-P) T

Apr 12 2014
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Apr 12, 2014 at 11:12:37PM +0000, froglegs wrote:
[...]
  Design flaws of C++? It may have a few, but compared to C? I think
 C++ is far better designed, and far safer.

Few?? Wow. How long have you been writing C++ code? Maybe you might find this enlightening: http://bartoszmilewski.com/2013/09/19/edward-chands/ :-) [...]
 Because C++ is more complex it requires more informed programmers to
 operate than C.
 
 If you have a team of informed C++ programmers I feel that it is very
 possible to produce very quickly, high quality reliable code. That all
 members can understand(I'd be inclined to say fire anyone that can't
 grok it, they will just be a liability).

Very quickly? Maybe. High quality? I doubt it. Maybe you're among the lucky few who can fire incompetent C++ programmers (or, shall we say, less-than-expert) at will. But in a large project with 50+ coders simultaneously working on the codebase, you're not going to have that luxury. And this is where C++'s flaws really become a pain in the neck. Even "informed" C++ programmers are not aware of all of the subtleties of the C++ standard -- and let's not fool ourselves, the C++ standard is huge, complex, and I doubt even Stroustroup himself can remember all of its details off the top of his head. In a 50+ member team, *somebody* is bound trip up on some detail that percolates through the code and causes very hard-to-find bugs. Compound this with upper management transferring people around at whim, and you've got a disaster in the making. At least with C, only competent people will even *get* the job in the first place, which solves about 50% of the problem. :P
  But anyway I do not understand why important software is still
 written in C. It makes me sad:(

You mean, like the Linux kernel? :-P Maybe you should take it up with Linus. I recommend buying reinforced fireproof armour first. :-P T -- Time flies like an arrow. Fruit flies like a banana.
Apr 12 2014
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Saturday, 12 April 2014 at 18:36:19 UTC, Marco Leise wrote:
 Am Fri, 11 Apr 2014 09:59:45 +0000
 schrieb "Chris" <wendlec tcd.ie>:

 In a way it's scary how vulnerable software we rely on still 
 is. I cannot claim that my software is immune to attacks, but 
 where security is crucial, one would expect self-critical 
 scrutiny rather than complacency. But we're all only human.

+1. My naive assumption was that something like SSH is implemented once and then bugs are fixed, so it can only ever become safer. I found it astounding that this library was totally sane only 2 years ago. One innocent commit is all it took and it can happen again for any software, any time. If crackers keep their eyes open they _will_ find their next backdoor.

I don't remember if this has been already posted here in the forum, but I think that this rant of Theo de Raadt about heartbleed is _very_ interesting. http://article.gmane.org/gmane.os.openbsd.misc/211963 TBW, I agree with him: it's not a matter of scrutiny or a matter of being human, and the post clarify this very well.
Apr 13 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 13 April 2014 at 08:55:47 UTC, Paulo Pinto wrote:
 20 years ago I would have answered both are bad and Object 
 Pascal/Delphi is the way.

 Sadly Borland did lots of major screw ups and let the language 
 momentum fade away.

Ironically, I have been using Pascal/Delphi at my first programming job. Switching later to C was a big relief - yes, it was less safe and sometimes awkward. But it did feel like a language designed by engineers, not academicians and that alone has boosted productivity a lot.
Apr 13 2014
prev sibling next sibling parent =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim gmail.com> writes:
--047d7b2e489aa33b6104f6edc1cc
Content-Type: text/plain; charset=UTF-8

On Sun, Apr 13, 2014 at 12:38 AM, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 C++ is better in theory, but not all that much better than C in
 practice. The design flaws of the language often makes it worse than C
 in terms of maintainability. At my day job, we switched a major project
 from C++ back to C, because the C++ codebase was over-engineered and
 full of abstractions that nobody understood, patched over multiple times
 by people who were reassigned to take the place of the original people
 who left, who didn't understand the original design but had unreasonable
 deadlines to meet, so as a result they just added hacks and workarounds
 to get their job done before they got fired. By the time a few years had
 passed, *nobody* understood what the system even does, and every new
 code change was a "blindly copy-n-paste from other parts of the code and
 pray it won't break something else" deal. It was bloated, slow, and
 riddled with bugs nobody dared to fix, because nobody understood what it
 does. Certain features were dependent on dtor side-effects, and other
 such pathological things, and it was maintenance hell.

I don't understand what is the C++ fault when the management of the project forces people to write shit. The same situation would have happen with any language and a full rewrite by a fixed team would have been better whatever the new language. I've heard the same story with Java, C# and Python in the last few years. Always management fault. I'm not sure I understand the arguments against C++ in your examples, in particular if you use D which have destructors and "magic" too. --047d7b2e489aa33b6104f6edc1cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">= On Sun, Apr 13, 2014 at 12:38 AM, H. S. Teoh <span dir=3D"ltr">&lt;<a href= =3D"mailto:hsteoh quickfur.ath.cx" target=3D"_blank">hsteoh quickfur.ath.cx= </a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div id=3D":22u" class=3D"a3s" style=3D"over= flow:hidden">C++ is better in theory, but not all that much better than C i= n<br> practice. The design flaws of the language often makes it worse than C<br> in terms of maintainability. At my day job, we switched a major project<br> from C++ back to C, because the C++ codebase was over-engineered and<br> full of abstractions that nobody understood, patched over multiple times<br=

who left, who didn&#39;t understand the original design but had unreasonabl= e<br> deadlines to meet, so as a result they just added hacks and workarounds<br> to get their job done before they got fired. By the time a few years had<br=

code change was a &quot;blindly copy-n-paste from other parts of the code a= nd<br> pray it won&#39;t break something else&quot; deal. It was bloated, slow, an= d<br> riddled with bugs nobody dared to fix, because nobody understood what it<br=

such pathological things, and it was maintenance hell.</div></blockquote></= div><br>I don&#39;t understand what is the C++ fault when the management of= the project forces people to=C2=A0</div><div class=3D"gmail_extra">write s= hit. The same situation would have happen with any language and a full rewr= ite by a fixed team</div> <div class=3D"gmail_extra">would have been better whatever the new language= .</div><div class=3D"gmail_extra">I&#39;ve heard the same story with Java, = C# and Python in the last few years. Always management fault.</div><div cla= ss=3D"gmail_extra"> <br></div><div class=3D"gmail_extra">I&#39;m not sure I understand the argu= ments against C++ in your examples, in particular if you use D which have d= estructors and &quot;magic&quot; too.</div><div class=3D"gmail_extra"><br><= /div> <div class=3D"gmail_extra"><br></div></div> --047d7b2e489aa33b6104f6edc1cc--
Apr 13 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 13 April 2014 at 15:17:30 UTC, Klaim - Joël Lamotte 
wrote:
 I don't understand what is the C++ fault when the management of 
 the project
 forces people to
 write shit. The same situation would have happen with any 
 language and a
 full rewrite by a fixed team
 would have been better whatever the new language.
 I've heard the same story with Java, C# and Python in the last 
 few years.
 Always management fault.

 I'm not sure I understand the arguments against C++ in your 
 examples, in
 particular if you use D which have destructors and "magic" too.

C++ fault is that it makes very easy even for experienced programmer to write faulty code and consequences of a mistake can be rather dire. C has similar issues but C is much smaller and simpler language which allows to keep all possible danger points in mind. I have yet to meet a single C++ programmer who can remember about all corner cases at the same time. I am not sure even Bjorne himself can. D makes situation much better by refining base semantics to adhere "safe by default, fast when explicitly asked" principle (array bounds checks, default initialization of locals). It is still not 100% consistent but greatly reduces stress of the context comparing to C++. I'd still prefer C++ over C for most projects but only if using very small well-defined subset of C++ verified by static analysis tool continuously.
Apr 13 2014
prev sibling next sibling parent "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
On Sunday, 13 April 2014 at 17:31:17 UTC, Walter Bright wrote:
 Interestingly, I've been seeing that what makes D code much 
 more robust is a consequence of 'unittest' coupled with -cov.

Built-in unittests are the best thing since jet engines.
Apr 13 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 13 April 2014 at 17:31:17 UTC, Walter Bright wrote:
 Interestingly, I've been seeing that what makes D code much 
 more robust is a consequence of 'unittest' coupled with -cov.

It is big deal breaker for personal projects and open-source collaboration. For big private projects agreeing on single testing framework and adding one of coverage analyzers to the CI is not that much of a problem. Convenient, but not a deal breaker over C++. But being less afraid to actually write code because of more powerful type system and safer defaults - this is huge. I think most important thing about built-in unittests is how this feature encourages to add tests when contributing to projects that don't currently have any real coverage. It becomes so easy that there is not reason to not do it and this help open-source a lot.
Apr 13 2014
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 13 Apr 2014 09:27:17 -0700
schrieb Walter Bright <newshound2 digitalmars.com>:

 On 4/13/2014 4:04 AM, Michel Fortin wrote:
 Interesting. As far as I know, the D GC is also a wrapper around malloc, and it
 will not return memory using free when an object is deallocated. That rant
could
 also apply to D.

You're right in that a malloc debugger would be ineffective when the D GC is used. But the D GC offers its own memory debugging features. They can be turned on with version identifiers in the GC source.

...and disabled by default. The point is, programmers who trade security for performance will now and then lose that gamble. They WILL circumvent whatever the language offers if they can gain speed from it. In D there is minimallyInitializedArray() for them and void-initializers or pointer arithmetic. -- Marco
Apr 14 2014
prev sibling parent "ed" <sillymongrel gmail.com> writes:
On Sunday, 13 April 2014 at 18:45:21 UTC, Paulo Pinto wrote:
 Am 13.04.2014 20:40, schrieb Walter Bright:
 On 4/13/2014 10:38 AM, Dicebot wrote:
 I think most important thing about built-in unittests is how 
 this feature
 encourages to add tests when contributing to projects that 
 don't
 currently have
 any real coverage. It becomes so easy that there is not 
 reason to not
 do it and
 this help open-source a lot.

Exactly. You can do unittests with other languages, too, but having it be so convenient, and no arguments about which unittest tool, is a game changer. The built-in -cov is also a game changer.

Until one gets lousy management in the picture. :( Sorry, just got a lousy week with developers deleting unit tests to "improve" their builds. -- Paulo

Wow, that would almost be a sacking offence where I work.
Apr 14 2014