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

 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)

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.

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.

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

 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

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.

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

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

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.