[SystemSafety] On open-sourcing coding standards

[Andrew Banks]

Hi Olwen

 

I won’t address your suggestion of vested interests, because  (quite sincerely) I don’t know to whom or what you refer – certainly my opinion of the member companies is that they have ensured tool neutrality… and the fact that so many other vendors incorporate MISRA is a testament to that effect.  Equally, I was not involved with MISRA-C:2004

 

But I’m more than happy to discuss your thought/ideas, either on or off list J

 

However, I can certainly share your frustration with SC22/WG14 and the C Standard – for a group that repeatedly claim that their standard isn’t broken, that WG14 itself has published ISO 17961 (C Secure) and SC22/WG23 have their complementary set of standards to address vulnerabilities, shows that the C Standard is broken!  As someone once said, if WG14 were doing their job properly, there would be no need for MISRA C (or CERT C for that matter)

 

As an aside, both AbsInt and Synopsis are members of MISRA C, as well as the more longstanding tool-vendors PRQA and LDRA (amongst others) – they clearly feel there is a beneficial nature of participation.

 

 

Regards

Andrew

Chairman, MISRA C Working Group

(and LDRA, not that this matters!)

 

From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Olwen Morgan
Sent: 18 September 2018 20:27
To: systemsafety at lists.techfak.uni-bielefeld.de
Subject: [SystemSafety] On open-sourcing coding standards

 


I have some sympathy with the idea that coding standards ought to be part of the open-source world but I can see some practical problems with the idea (as well as problems with coding standards that are not open-source). Here goes:

I've already spoken of document N0228 on the ISO/IEC-JTC1/SC22/WG23 web site, which I prepared while participating in the work of the BSI Panel on language vulnerabilities. One of the reasons I allowed that document to go forward as a Canadian contribution is that it coincided more or less with the release of the CERT C coding standard by Robert Seacord and his colleagues. I don't very much like the CERT standards that I've seen because they do not separate the issues of precise identification of language constructs and the controls that need to be applied to them. My N0228 document worked through all of the C99 standard, under the same headings as the standard, identifying where particular language constructs needed to be identified and using the SYMELAR syntactic metanotation to specify them.

Developers of commercial coding standard checkers have an incentive not to want coding standards to be written in this way because it is not hard to write a checker that is driven directly off the metanotation. Indeed, I strongly suspect that certain vested commercial interests (no names, no pack drill - but you could easily find out who I mean) made sure that MISRA C 2004 made only minimal use of the metanotation. Open-source development of an adaptable multi-purpose C coding standard ought, free from vested commercial interests, to escape such pressures.

If you look at N0228,  and compare it with the MISRA C documents, you should be able to see fairly easily which constructs are the subject of MISRA C rules and how, therefore, to construct a coding standard technically equivalent to MISRA C (whichever version you choose) simply by constructing a table showing what controls apply to which identified constructs. Indeed if the developers of the latest MISRA C standard had done this, they could have made the work of producing a standard considerably easier for themselves - albeit at the expense of p!ssing off the said vested interests.

The C11 standard runs to 700+ pages. Doing for C11 what I did for C99 is therefore not a small exercise. On the other hand, nor would it be a particularly difficult thing to do. Indeed I have been wondering of late whether I ought to make use of my current semi-retired status to do just that. That said, however, there are some possible non-commercial objections to going that way. One, which was raised early in the development of MISRA C 2004, is that the user constituency for the standard "would find the syntactic metanotation too unfamiliar". My response to that is that SYMELAR is simply a slightly augmented form of BNF, and if a software engineer does not understand BNF, he/she shouldn't be working on critical systems (and a significant number thereof should, IMO, be taken out and shot). Nevertheless, acceptability to users cannot be wholly ignored, if only to avoid treading on political landmines.

Another more substantial argument is that given a set of coding rules, the developer of a checker tool has a wide choice of how to enforce them. There is, for example, quite a difference between, say, QAC and the corresponding LDRA checker in what constructs their checkers actually look for. Maldadroit choice of designated constructs could easily and unfairly favour one existing tool over another. (Having been most familiar with QAC, I got some pointed comments from various people from LDRA when I gave SYMELAR definitions as input to the early stages of developing MISRA C 2004.) This problem, however, can be addressed by looking at the messages that individual tools produce. I had access to the entire repertoire of QAC diagnostic messages but not to those of the LDRA tools, which was understandable in the circumstances but nonetheless unhelpful.

As it happens I am currently working my way through the C11 standard in connection with one of my current back-burner projects. But, by hook or by crook, I could probably get the current C11 document into MS Word and then do another N0228 style document that I would be happy to put into an open-source coding standard project. I expect, however, that this would elicit vigorous objections from the current MISRA C working group, not to mention various (IMO incompetent) sources within ISO/IEC-JTC1/SC22/WG14, where there seems to be no culture sympathetic to - or even technically aware of - the needs of critical systems development.

Having seen how MISRA C has gone since 2002, I am singularly unimpressed by the results and have, I am afraid, very little confidence in the ability of that working group collectively to make the kind of technical progress with the standard that would make it robust enough to be acceptable for SIL3/4 work (which it is nowhere near right now). As regards the C standard, my confidence in WG14 is not describable in polite terms. These days I regard the processes of international and industry-sector standardisation as dysfunctional and currently incapable of producing either languages or coding standards that are truly suited to the highest levels of system criticality (SPARK Ada being a lone commendable exception).

On a more positive note, I am very impressed with French work in this area on analysis tools, notably Frama C and AbsInt - the commercialised version of Astree. If the developers of those tools have pressed ahead because they have given up on standardisation dominated by a single, delapidated, national technical culture, then I wish them a huge "bonne chance" (which, coming from a deeply anglo-sceptic Welshwoman, is about what you should expect).


Tin hats on and head to the nuclear bunkers,

Olwen







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20180919/de801e88/attachment-0001.html>