[SystemSafety] OpenSSL Bug

[Patrick Graydon]

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