[SystemSafety] On open-sourcing coding standards

[Olwen Morgan]

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/20180918/1f22fa0a/attachment-0001.html>