[SystemSafety] OpenSSL Bug

[Steve Tockey]

Dave,
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,

-- steve



-----Original Message-----
From: David Haworth <david.haworth at elektrobit.com>
Organization: Elektrobit Automotive GmbH
Date: Wednesday, April 16, 2014 4:08 AM
To: "systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] OpenSSL Bug

Hi,

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.

So

    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.

@Steve: this isn't aimed at you especially - you just happen to
be the most recent person to quote this nonsensical example.

Dave


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
david.haworth at elektrobit.com
Tel: +49 9131 7701-6154     Fax: -6333                  Keys:
keyserver.pgp.com
Elektrobit Automotive GmbH           Am Wolfsmantel 46, 91058 Erlangen,
Germany
Geschäftsführer: Alexander Kocher, Gregor Zink       Amtsgericht Fürth HRB
4886