[SystemSafety] OpenSSL Bug

[David Crocker]

Regarding the use of language subsets to reduce the occurrence of coding
errors in C and C++, I published a short article in the January 2009
edition of the SCSC newsletter called "Some Common C/C++ Coding Errors
and Their Occurrence Rates" (available via http://scsc.org.uk/p106).
This gave figures for densities of some types of coding error found in a
large body of production C++ code having many different authors, based
on a very shallow static analysis of the code. All these coding errors
would violate at least one MISRA rule. This is evidence that to me at
least that *some* of the MISRA rules are valuable in reducing coding
errors. Sadly I cannot release the original data or more detail due to
commercial confidentiality, so I understand if others decline to accept
this as evidence.

Although in most cases the code could be changed to avoid the "rule
violations" with little risk of introducing further errors, there was
one type of rule violation (mixing signed and unsigned variables in
comparison expressions) which detected very few errors, but for which
the risk of introducing errors when the code was changed to comply with
the rule was very high. So it is not necessarily a good idea to apply
all the rules from MISRA or some other coding standard retrospectively.

One thing we should urge the FOSS community to do is to at least turn up
the warning levels on their C and C++ compilers to maximum. Most
compilers are able to warn about some common types of coding error when
this is done. In Escher Verification Studio we make use of a FOSS
graphical user interface framework called wxWidgets, and I am pleased to
say that is indeed compiled with warning levels turned up to maximum for
the two compilers (Microsoft Visual C++ and g++) that we use. My emails
to the primary developers a number of years ago may have helped bring
this about.

David Crocker, Escher Technologies Ltd.
http://www.eschertech.com
Tel. +44 (0)20 8144 3265 or +44 (0)7977 211486

On 15/04/2014 12:13, Patrick Graydon wrote:
> On 15 Apr 2014, at 12:40, Chris Hills <safetyyork at phaedsys.com> wrote:
>
>> How is FOSS code different to any other code?  
> I have no idea.  I only limited my question to FOSS because it was in response to your message about getting FOSS developers to adhere to MISRA-C.
>
>
>> Since the Hatton reports in 2007 we have moved on to MISRA C:2012. 
> And?  What evidence do you know of that shows that the new formulation is any more effective at reducing the rate at which programmers make errors generally or errors with large safety or security impacts specifically?
>
>
>> MISRA-C rules work to reduce the "problem areas" for C that if used without
>> care can cause problems. Especially if in the vicinity of other problem
>> areas used without care.  
> This is a claim.  I asked for evidence.
>
>
>> MISRA-C for example insists on {} for single line If constructs apparently a
>> real PITA to those who "know what they are doing".   However that rule would
>> have caused a query with the Apple SSL goto problem in their if statements
>> before it got as far as compilation. 
> A single example is not evidence of a difference in defects rates.
>
>
>> Actually my understanding re the MISRA-C rules introducing a critical
>> defect, from memory and discussions within the MISRA-C group the problems
>> tend to be by "cleaning" some code it uncovers problems in another area.
> Second-hand anecdotes.  Where is the data?
>
> I cited evidence that shows that the MISRA-C rules (at least the old ones) are not, as a whole, effective at reducing the rate at which programmers introduce defects. It isn’t perfect evidence.  But where is the evidence (not suppositions, not unfounded claims, not anecdotes, not superstition) to the contrary?
>
> Please note that I ask in the spirit of inquiry.  I have no ideological opposition to the idea that MISRA-C is better than unrestricted C.  Rather the opposite: it would be nice to know that doing something as simple as conforming could improve C code quality.  But I go where the evidence leads.
>
> — Patrick
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE