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
parent reply 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
next sibling parent reply "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
next sibling parent reply "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
next sibling parent reply "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
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 reply "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
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 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
parent reply "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
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 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 parent reply =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim gmail.com> writes:
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.

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.
Apr 13 2014
parent reply "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.

 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
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
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 parent reply "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
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 reply 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
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
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 parent reply "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
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 reply 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
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 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
parent reply "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
parent reply "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
next sibling parent reply "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
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 reply "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
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