Re: Safe ANSI C Subset

In 96-12-030, "Jan Soderberg" <Jan.Soderberg@mecel.se> writes:
>Does anyone know of any ANSI C subsets defined for safety critical
>real-time applications?


We are checking a safe subset of C in the ESPRIT project
OMI/ANTICRASH. Our checkers are integrated in to the ANDF compiler
technology ( a source filter for software metrics and an ANDF tool for
intermodular and linkage checking) and we developed a model that fits
well into the software development life-cycle.


First of all you should check out Les Hatton's book 'Safer C',
McGraw-Hill 1995. You will find there most aspects of C in the safety
-critical software development environment.


Our customer defined a 'presumed' safe subset of C for implementing a braking
system as an embedded hard real-time system, just because they need
certification credit by RCTA (DO178B safety standard).


1. They defined _some_ internal development guidelines
2. In these guidelines they required totally uncertain things like
      enough and precise comments and source layouts but they also excluded
      goto and union keywords. Non-reentrant code, dynamic data and recursive
      routines are also forbidden. No standard headers or standard libraries
      are allowed, except of certified ones.
3. Traceability is of major concern for the certification so naming conventions
      for files and routines are prescribed.


They defined a lot of things more (I am not permitted to post them all
because the document is confidential) but these things have been very
uncertain similar to the commenting item. However, I wrote a paper
called 'Applying the ANDF technology for hard real-time systems' for
the EMSYS96 conference in Berlin (Embedded Microprocessor Systems,
Mueller-Schloer, IOS Press about that topic.


I want to emphasise that standards without checking are completely
useless. Certain aspects of C subsets have to be checked during code
reviews which might increase the costs for such activities. Our
approach was to map these uncertain standard phrases to concrete
checkable topics. Most of them are strict API checking but we
incorporate also software metrics and demanded for example to have 30
% comments in the code, a limit of 15 for McCabe's cyclomatic
complexity, a limit of 100 of executable lines of code and only one
exit in a routine.


We experienced that:
1. You will need more than just ANSI C compliance
2. You have to control the whole tool chain : Preprocessing, codegeneration,
        linking and running.
3. There are always some assumptions in code, but they have to be explicit
        e.g. data conversion.


Best regards
Heiner
------------- URL http://www.uni-karlsruhe.de/~ae59 ---------------------
Heinrich Berlejung |Institut f. Angewandte Mathematik
Tel.:+49 721 377936 / Fax:+49 721 385979 |P.O. Box 6980,D-76128 Karlsruhe
Mail:Heiner.Berlejung@math.uni-karlsruhe.de|Universitaet Karlsruhe (TH)
--

Return to the comp.compilers page.
Search the comp.compilers archives again.