Re: [SystemSafety] OpenSSL Bug

From: David Crocker < >
Date: Tue, 15 Apr 2014 13:37:46 +0100


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_xxxxxx >
>> 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_xxxxxx



The System Safety Mailing List
systemsafety_at_xxxxxx Received on Tue Apr 15 2014 - 14:37:57 CEST

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