[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