[SystemSafety] New paper on MISRA C

Olwen Morgan olwen.morgan at btinternet.com
Sun Sep 16 16:34:10 CEST 2018


Hi All,

I'm with Mario Gleirscher here and I'll explain why.

In the 1990s i did two large contracts, one for BT and one for 
Programming Research. While at BT, I wrote three standards relating to 
the use of C and C++ in network management software. I went from BT to 
Programming Research (PRL) in 1995. Early in 1997, Austin Rover Group 
(ARG) sent a draft C coding standard to PRL for review. It was given to 
me and I had three days to read and review it. To be frank, I considered 
the ARG draft very poor. My review comments essentially rewrote the 
draft to be closer to something that I thought would be suitable. A few 
months after I finished the review, PRL was sent a copy of draft 0.1 of 
the MISRA C coding rules. It had largely replaced the original ARG rules 
with those that I had proposed in my review, although some rules had 
been weakened and some omitted.

I think it right to point out that when I did the review of the ARG 
draft, I had very little time to complete it and more or less did a 
brain dump onto the back of an envelope to produce my review. What 
happened between that and the publication of the first MISRA C document 
in 1998 was that the people working on it looked for empirical evidence 
of the usefulness of the rules that I had proposed. Hence, since some of 
my proposals were made on theoretical grounds, not all of them actually 
went into the first MISRA C standard. I and pretty well everyone else at 
PRL were, I think it right to say, rather surprised that a three-day 
brain-dump had morphed into a sectoral standard.

Here, therefore, let me set out what I consider were the shortcomings of 
MISRA C from the outset:

1.    The language of my brain-dump review was not of the quality that I 
would have expected to see in, say, a British Standard. In fact, when 
commenting on the MISRA C 0.1 draft, I recall recommending that the 
editors adopt BSI editorial standards. They chose not to do this.

2.    My view at the time, and still today, is that coding standards 
should separate the notions of which constructs need to be controlled 
from the actual controls applied to them in any given context of use. 
IMO, none of the MISRA C documents does this satisfactorily.

3.    In 2002, when the second version of MISRA C was on the drawing 
board, I recommended the use of a syntactic metalanguage for precise 
identification of the kinds of constructs that need to be controlled. 
Along with that, supported by PRL, I produced a rule-by-rule critique of 
MISRA C 1998 for which I devised a metalanguage called SYMELAR (= 
SYntactic MEtanotation for LAnguage Restriction) and recast as many 
rules as I could using SYMELAR to identify the construct to which they 
applied. The MISRA C working group did not adopt my suggestions except 
for the rules concerning the switch statement.

( I later used SYMELAR as part of submission to ISO/IEC JTC1/WG23 on 
language vulnerabilities. BSI declined to submit it as a UK contribution 
but the international convenor asked me if I would mind if CSA submitted 
it as a Canadian contribution, which ultimately it was. That document is 
still on the WG23 web site as documentN0228 Programming Languages - C - 
Designated Constructs. It's a pdf made from a MS Word Document and 
unfortunately has a ToC saying that some headings are missing owing to 
an error of mine in not regenerating the ToC after some last-minute 
editing. The whole text is, however, present in the body of the 
document. I have sincew devised a more concise form of SYMELAR for which 
it would be relatively straightforward to construct a generator of 
type-checking parsers that would identify controlled constructs 
automatically.))


4.       While it was perfectly reasonable for those who drafted MISRA C 
1998 to look for empirical evidence for the rules, this led to three of 
my proposed rules being dropped. These were:

         (a)    always declare variables in the smallest possible scope 
(introducing a nested scope if necessary)

         (b)    always initialise variables at declaration,

         (c)    assign to a variable in exactly one place within its scope.

Together these rules mandate essentially a single-assignment style. 
Their justification is twofold. First, they facilitate easy extraction 
of local loop invariants. Second, where a nested scope is introduced, it 
does not increase the complexity of the frame problem for the 
surrounding context. These characteristics (usually) make program 
verification much easier for abstract interpretation or program-proving 
tools. The people who were looking for empirical evidence to support 
rules possibly did not realise that these rules were motivated by sound 
theoretical considerations, possibly because they were not looking 
forward to the point where abstract interpreters and program provers 
would come into widespread use. I have actually programmed in this style 
for over 20 years and I find that it makes my code significantly simpler 
in structure than it would otherwise be.

5.        None of the MISRA C standards addresses the limitations of 
program structural complexity. This is a serious weakness. Such 
limitation is essential in order to;

         (a)    minimise the size of test coverage domains, and

          (b)    more importantly, render programs more tractable to 
static analysis by abstract interpretation and program-proving tools.

 From a technical point of view, items 4 and 5 above reflect serious 
weaknesses in the current MISRA C document. It is, IMO, simply not good 
enough for a coding standard for critical systems to ignore testability 
and provability issue to the extent that the current MISRA C document 
does. I pointed out the testability weakness at the time I reviewed the 
ARG document but was ignored. I was again ignored on using a syntactic 
metalanguage, and ignored yet again on rules designed to make code more 
tractable to formal verification.

In my view MISRA C is a decent starting point for a standard that truly 
addresses the exigiencies of safety-critical systems, but it is still 
*only a starting point even if it is surrounded by a good development 
process*. If I had known that my brain-dump onto an envelope was going 
to become MISRA C, I would have been much more insistent on points 4 and 
5 above.


kind regards,
Olwen Morgan



On 15/09/18 14:20, Andrew Banks wrote:
> Mario Gleirscher wrote
>> If you think, by using a static checking tool claiming to cover all of automatable MISRA C and you are fine, then I would say: You are lost!
>>
> Absolutely... even MISRA C itself states that "MISRA C is intended to be used within the framework of a documented software development process".
>
> A
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
>

-- 
Olwen Morgan CITP, MBCS olwen.morgan at btinternet.com +44 (0) 7854 899667 
Carmarthenshire, Wales, UK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20180916/2d7ed015/attachment.html>


More information about the systemsafety mailing list