Re: MISRA C (was: Industry support groups that foster secure/quality coding practices)

[Steve Litt <slitt () troubleshooters com>]

Curious: Why would one mandate O-O for embedded applications? I would think 
that with memory constraints etc, for simple embedded apps, a simple top-down 
structure would result in faster code, less memory usage.

If your app is designed to model physical objects (the Joint Strike Fighter, 
etc), I take back the preceding paragraph.

I'm not an embedded guy -- mostly office automation and the like, but I use C 
less and less these days. With pointer arithmetic, there's very little way I 
can prove to myself that my code does not contain an errant pointer that 
will, upon just the right set of circumstances, do something stupid. The 
MISRA spec you mention sounds interesting, as it might prevent me from making 
those errant pointer errors.

I use a lot of Perl these days. Develops lightning fast, no pointers, and it's 
ubituqitous and portable. Not exactly high performance, and Perl can be 
authored as write-only code, but if done right and used for the right 
applications, it's a way of getting things done lightning fast, with 
reasonable performance in applications where raw processor power is not the 
bottleneck.

Steve

Steve Litt
Author: 
   * Universal Troubleshooting Process courseware
   * Troubleshooting Techniques of the Successful Technologist
   * Rapid Learning: Secret Weapon of the Successful Technologist
Webmaster
   * Troubleshooters.Com
   * http://www.troubleshooters.com

(Legal Disclaimer) Follow these suggestions at your own risk.


On Wednesday 31 December 2003 06:17 pm, David Crocker wrote:
> MISRA C is widely used in the automotive industry. I have been told (but
> not had confirmation) that MISRA C was also the basis of the standard used
> for coding new software for the Joint Strike Fighter.
>
> The MISRA C standard comprises 127 rules banning various constructs and
> library calls. Most of these are designed to avoid areas of C where the
> behaviour is undefined, implementation-dependent, or liable to cause
> inadvertent errors. A few of the rules are there because the authors
> believe they help to promote "good style". Conformance with most (but not
> all) of the rules can be checked statically.
>
> A number of deficiencies have been identified in the original MISRA
> standard; version 2 of the standard is being developed to address these.
>
> Personally, I agree that C is not a good place to start from for reliable
> applications (see my earlier rant about why C is a dreadful language).
> However, for many embedded processors, there are few (if any) other
> languages supported. Despite the limitations of MISRA C, I believe that
> coding in MISRA C and using a good tool to check for conformance with the
> standard (as far as is possible) is significantly better (from a safety &
> security point of view) than coding in plain C.
>
> What I would like to see is a widely-implemented, well-designed, type-safe
> object-oriented language. Eiffel comes close but is not widely implemented
> or used. The present version of Ada (95) is a poor choice for serious O-O
> development. Maybe in future we will see a C++ subset based on extending
> the MISRA standard.
>
> Our own practice is to specify software using a custom O-O specification
> and refinement language, prove that the specification meets the functional
> requirements, then generate all the code in a MISRA-like C++ subset (or
> Java in some cases). By using C++ as a sort of high-level assembler for our
> code generators to target, we avoid the traps that humans encounter when
> writing in it.
>
> David Crocker
> Escher Technologies Ltd.
> www.eschertech.com
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of ljknews
> Sent: 31 December 2003 16:37
> To: [EMAIL PROTECTED]
> Subject: Re: [SC-L] Industry support groups that foster secure/quality
> coding practices
>
> At 9:53 AM -0500 12/31/03, Kenneth R. van Wyk wrote:
> > In any event, is anyone here aware of MISRA?
>
> MISRA (the standard) has been widely discussed in comp.lang.ada lately.
>
> There are various advocacy positions taken whether MISRA (the organization)
> did admit that trying to use C for safety-critical work was a weak
> substitute for using another language.