Re: [SystemSafety] OpenSSL Bug

From: Steve Tockey < >
Date: Wed, 16 Apr 2014 11:23:14 +0000

No offense inferred, but thanks for pointing it out.

Besides, echoing this and Derek M. Jones' last post, I think this whole discussion is focusing on relatively minor issues and completely missing the big picture. Specifically, the data that I have shows that 56% of defects in a typical project's defect tracking database are rooted in requirements. The requirements were vague, ambiguous, or just missing altogether. 27% of defects were rooted in design: inappropriate algorithms and data structures were chosen. A mere 7% of defects are coding injected, as in single equals vs. double equals or inappropriate use of typing.

Why are we wasting time debating coding level issues when they aren't where the real problems lie? Simply, if 56% of defects are requirements injected and 27% are design injected, then the simple fact is that 83% of all defects exist before a single line of code was ever written. Why aren't we attacking the 83%, not the 7%??? Requirements and design defects outnumber coding defects by more than 10 to 1.

I'd be willing to bet that the studies cited before where one couldn't correlate defects with use of a particular language, would actually correlate quite well with the sanity (or lack thereof) of the requirements, design, and review practices used by each of those teams. A team with good requirements, design, and review practices can write good, safe code in any language, including C. A team with stupid requirements, design, and review practices writes crappy code in any language. Strong typing and no-assignments-in-if-statements aren't going to bail anyone out of having shitty, ill-conceived requirements and design. Period.

Just my two cents,

-----Original Message-----
From: David Haworth <david.haworth_at_xxxxxx Organization: Elektrobit Automotive GmbH Date: Wednesday, April 16, 2014 4:08 AM
To: "systemsafety_at_xxxxxx <systemsafety_at_xxxxxx Subject: Re: [SystemSafety] OpenSSL Bug


I was trying to keep out of this, but I'm starting to get sick of this particular example.

    if ((a = check()) = SUCCESS) { ... }

fails to compile because (a = check()) is not an lvalue.


    if ((a = check()) == SUCCESS) { ... }

is a perfectly safe construct. Unless, of course, what you really intended to write was

    if ((a == check()) == SUCCESS) { ... }

in which case you should take yourself out and shoot yourself for comparing an effectively boolean result with a specific numerical value.

_at_xxxxxx be the most recent person to quote this nonsensical example.


On 2014-04-16 10:17:41 +0000, Steve Tockey wrote:
> I'm not arguing for or against C, but I have seen coding standards that
> prohibit:
> if ((a = check()) == SUCCESS) { ... }
> They require instead:
> if ( SUCCESS == (a = check()) ) { ... }
> Simply moving the constant to the left side makes it an ill-formed
> expression if the "==" is accidentally switched for "=":
> if ( SUCCESS = (a = check()) ) { ... }
> -- steve

David Haworth B.Sc.(Hons.), OS Kernel Developer
Tel: +49 9131 7701-6154     Fax: -6333                  Keys:
Elektrobit Automotive GmbH           Am Wolfsmantel 46, 91058 Erlangen,
Geschäftsführer: Alexander Kocher, Gregor Zink       Amtsgericht Fürth HRB

The System Safety Mailing List
Received on Wed Apr 16 2014 - 13:23:28 CEST

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:06 CEST