misrac

HIGHLIGHTSBased on MISRA —“Guidelines for the Use ofthe C Language in VehicleBased Software”

Selectable restrictions to ISO/IEC 9899:1990standard C programminglanguage

TASKING is the onlytoolset to include theseunique code checkingfacilities in standard C compiler tools

Supported on manyTASKING compiler tools,including C166, ST10,TriCore, ARM, M16C, XAand 8051

Well suited for safetyrelated or mission-criticalapplications, or wheregeneral quality androbustness of code are important

MISRA CTM SUPPORT DELIVERS ROBUST CODE

The C programming language is today's de facto standard for high-level language programming ofembedded systems. Unfortunately, drawbacks in consistency and intrinsic quality make C somewhatunsuitable for programming safety-related applications. Through enhanced code checking and strictenforcement of best practice programming rules, TASKING’s MISRA CTM code checking helpsprogrammers produce more robust code.

Since February 1999, TASKING has been the only toolset to include unique facilities in standard Ccompiler tools that help programmers produce code that conforms to the guidelines defined by MISRA®

(Motor Industry Software Reliability Association, www.misra.org.uk). These guidelines are a major benefitto programmers of embedded products in safety-related areas such as automotive, industrial control,communications, medical, and aerospace. But they are also valuable to any programmer of embeddedapplications concerned with the general quality and robustness of their work.

THE C LANGUAGE IN EMBEDDED SYSTEMSIn the last decade, an increasing percentage of embedded microprocessor applications have been written in theprogramming language C. In fact, C has turned into the de facto standard for higher-level language programmingof embedded applications.

A number of causes have led to the increased popularity of C in this area:

The ever-increasing complexity of applications drives programmers from assembly to the high-level languages.The high-level programming language C offers good support for high-speed, low-level I/O operations. Programmers of embedded applications particularly appreciate this mixed high/low-level approach.In comparison to other high-level language compilers, C language compilers tend to deliver more condensed code size. With product costs in mind, this is generally considered a very important issue.Virtually all mathematical modelling tools generate C source code.C offers significant productivity gains with opportunities for code re-use, improved code maintenance, and ongoing developments over the life of the application.

However, using a high-level language such as C does not guaranteeproblem-free code.

C can be written in a structured manner that reduces the chance ofproducing errors. But C can also be written in a very condensedmanner, which is hard to comprehend and dramatically increases thelikelihood of introducing errors.

The compiler does not necessarily detect small typing errors.Consider the operators &&, &, ||, |, +=, =, and ==, and think of theease with which a typo will still lead to perfectly valid C code.

Not every programmer is fully aware of the effects of all the possibleconstructs in the C language. For instance, casts (implicit or explicit)can cause both confusion and errors.

A number of the features in C have not been well defined. Other definitions of C features differ fromwhat the programmer would expect. Some compiler behavior is left undefined in the ISO C standard.

One of the main reasons that Ccompilers do a great job of generatingcompact, efficient code is because ofthe limited run-time checking in C.There are no provisions in C thatwould prevent arithmetic exceptionssuch as divide by zero, overflow,validity of addresses or pointers, orsurpassing array boundaries fromcausing a runtime software failure.

It is therefore easy to understand that programmers with a special interest in writing robust, consistent code have a concern withthe programming language C.

MISRA CTM

CODE CHECKING

if ((x = y) != 0)

MISRA C rule 35 violation:Assignment operators shallnot be used in Booleanexpressions

Wouldn’t you like to bewarned for a construct

like this?

The following list highlights some of the techniques thatare contained in the MISRA C guidelines.

In the group ‘Comments’, nested comments areprohibited and it is advised not to comment out sectionsof code.

In the group ‘Identifiers’, a limit is defined of max 31-character significance, and the use of identical identifiersis discouraged.

In the group ‘Types’, the basic types char, int, short, long,float and double should be replaced with typedefsindicating the specific length (e.g., SI_16 for a 16 bitsigned integer) and the type char shall always bedeclared as either unsigned char or signed char.

By definition, ANSI/ISO Ccompilers interpret decimalinteger constants withleading zeros as Octal. Toprevent confusing Octal andInteger constants, the use ofOctal constants is prohibited.

In the group ‘Conversions’, theuse of implicit typeconversions as well asredundant explicit casts areprohibited.

In the group ‘Expressions’, arule describes that the value of an expression should be the sameunder any permissible order of evaluation, and floating-pointvariables are not to be tested for exact equality or inequality.

In the group ‘Control Flow’, the use of goto, break and continue isprohibited. Also a number of constraints on the use of the if, else,switch, and case constructs is defined.

The group ‘Functions’ defines a large number of required rules onthe declaration and use of functions.

The group ‘Pointers and Arrays’ prohibits the use of non-constantpointers to functions and discourages the use of pointer arithmetic at all.

The group ‘Structures andUnions’ requires that allstructure/ union membersare named and referred toby name only.

This is only a smallsampling from the 127rules that have beendefined in the MISRA Cguidelines. For a completereference, read theGuidelines for the Use ofthe C Language in VehicleBased Software by MISRA.

MISRA C CONCEPT

C is accepted as the standard for higher-levellanguage programming in embeddedsystems, yet it is considered unsuitable forprogramming safety-related applications. If asafety-related application needs to beprogrammed in a higher-level language, and Cis the language of choice, then there areways to avoid the drawbacks of C. Many ofthe companies developing safety-relatedembedded applications have writtenguidelines to restrict the use of error-prone Cconstructs with the intention of reducing the probability of errors.

Based on experience andexpertise in automotiveapplications, as well asinformation from a number ofpublic-domain sources, theMotor Industry SoftwareReliability Association (MISRA)defined a total of 127programming rules applicablewhen developing safety-relatedapplications in C. In Guidelinesfor the Use of the C Language inVehicle Based Software (MISRA

C guidelines), MISRA has defined a core list of required rules andsupplementary set of advisory rules.

Although the MISRA C guidelines prescribe a wide range ofprogramming techniques, they can also be interpreted as applying asubset of the C programming language that is intended to besuitable for safety-related applications. Conformance can be checkedby reviewing the code manually, byusing static code analysis tools, orby invoking integrated restrictions inthe embedded softwaredevelopment tools.

if (si++ ||(ei == 11))

MISRA C rule 34 violation:The operands of a logical&& or || shall be primaryexpressions


like this?

for (F=0.0; F<10.0; F++)

MISRA C rule 65 violation:Floating Point variables shall not beused as loop counters

Wouldn’t you like to be warned for a construct

like this?

A = 111;B = 101;C = 011;

MISRA C rule 19 violation:Octal Constants (other thanzero) shall not be used


like this?

I=((I==2) && (J<<=1))

MISRA C rule 35 violation:Assignment operators shallnot be used in Booleanexpressions


like this?

I=(C<<8)

MISRA C rule 38 violation:A shift count shall bebetween 0 and the operandwidth minus 1


like this?

TASKING AND MISRA C CODE CHECKING

As a result of the close involvement in thedevelopment of the Infineon Technologies TriCore

TM

32-bit unified microcontroller-DSP architecture,TASKING received requirements from theautomotive industry to incorporate dedicatedsupport for the development of safety-related applications into their TriCoresoftware development tools.

Since the initial release of the TriCore tools inFebruary 1999, TASKING has remained the onlytoolset to integrate facilities for the enforcement ofbest practice programming into their embeddedsoftware developmenttool suites. Today,MISRA C codechecking is broadlyadopted and availablein many TASKING toolchains, includingInfineon TriCore and C166,STMicroelectronicsST10, MitsubishiM16C, Philips XA, and8051 (more than twodozen manufacturerssupported).

The TASKING embedded software developmenttools generally consist of a C/C++ compiler, Macro-assembler, Linker/Locator tools, a professionaleditor, and the CrossView Pro debugger. TheEmbedded Development Environment (EDE)integrates all these tools and offers an easy-to-learn/easy-to-use interface for all of the necessarytools settings and configuration of the target.

The TASKING C-compiler front-end technology hasbeen enhanced with additional code checks thatconform to the MISRA C rules. During compilationof the code, violations of the enabled MISRA Crules are indicated with error messages and the

build process is halted. The error messages clearlyidentify where and how the programmer wentwrong and guide the user toward compliance withbest practice programming standards.

A pull down configuration menu in EDE allows theactivation of the MISRA C rules to be applied for aparticular project. A predefined configuration forconformance with the required rules in the MISRAC guidelines is readily available.

Alternatively, it is possible to read C settings froman external configuration file. This feature isparticularly useful in situations where thedevelopment team needs to comply with a specific

set of MISRA C rules undermanagement by the company’s QualityAssurance department.

To ensure compliance with the MISRAC rules throughout the entire project,the Linker/Locator is able to generate aMISRA C report. This report lists thedifferent modules in the project with therespective MISRA C settings at thetime of compilation. Filed in thecompany's quality assurance system,this report can provide proof thatcompany rules for best practiceprogramming have been applied in theparticular project.

So, under theguidance ofMISRA C codechecking in theTASKINGembeddedsoftwaredevelopmenttools,programmers cannow write codethat containsfewer error-prone C constructs and consequentlydevelop more robust embedded systems.

This will be profitable for many application areas,including safety-relatedapplication areas such as theautomotive industry, whichdeveloped the guidelines onwhich MISRA C code checkingis based, as well as medical,industrial automation,communications, computer,and aerospace applications.

From Lehman Brothers:

“Since pioneering the concept of 'cross-development' over 20 yearsago, TASKING has been theindustry leader in thedevelopment, manufacture,and support of softwaredevelopment tools, such as C/C++ compilersand debuggers formicrocontrollers/processorsand DSPs.”

With the introduction ofMISRA C advanced codechecking, TASKING hascontinued this long traditionof innovation in compilertechnology.

if (EF==0)

MISRA C rule 50 violation:Floating Point variablesshall not be tested for exactequality or inequality


like this?

MY_UCHAR uc;MY_SHORT si;...uc=si;

MISRA C rule 43 violation:Don’t use implicit conversionswhich may result ininformation loss


like this?

AA LL TT II UU MM SS AA LL EE SS OO FF FF II CC EE SS

NNoorrtthh AAmmeerriiccaa

AAllttiiuumm IInncc17140 Bernardo Center Drive, Suite 100San Diego, CA 92128Toll Free: 1 877 TASKINGTel: +1 858 521 4280Fax: +1 858 485 4610Email: [email protected]

AAssiiaa –– PPaacciiffiicc

JJaappaann –– AAllttiiuumm JJaappaann KK..KK..Resona Gotanda Building 7F1-23-9, Nishi-GotandaShinagawa-ku Tokyo 141-0031Tel: +81 3 5436 2501Fax: +81 3 5436 2505Email: [email protected]

CChhiinnaa –– AAllttiiuumm IInnffoorrmmaattiioonn TTeecchhnnoollooggyy ((SShhaanngghhaaii)) CCoo..,, LLttdd..Suite A&J, Floor 9, Hua Du Mansion828-838 Zhang Yang RoadPudong New Area, ShanghaiTel: +86 21 6876 4016Fax: +86 21 6876 4015Email: [email protected]

AAuussttrraalliiaa –– AAllttiiuumm LLiimmiitteeddLevel 3, 12a Rodborough RoadFrenchs Forest NSW 2086Free Call: 1800 030 949Tel: +61 2 9975 7710Fax: +61 2 9975 7720Email: [email protected]

EEuurrooppee

GGeerrmmaannyy –– AAllttiiuumm EEuurrooppee GGmmbbHHAlbert-Nestler-Straße 776131 KarlsruheFree Call: 0800 0 258486 (0800 0 ALTIUM)Tel: +49 (0) 721 8244 300Fax: +49 (0) 721 8244 320Email: [email protected]

SSwwiittzzeerrllaanndd –– PPrrootteell AAGG(A subsidiary of Altium Limited)

Clarastrasse 124058 BaselTel: +41 (0) 61 666 68 68Fax: +41 (0) 61 666 68 69Email: [email protected]

FFrraannccee –– PPrrootteell AAGG(A subsidiary of Altium Limited)

121 rue d'Aguesseau92100 Boulogne-BillancourtPh: 0800 88 05 06Fax: 0800 82 85 92Email: [email protected]

www.altium.com/tasking

2567

- CO

LL02

GE1

Copyright © 2006 Altium Limited. Altium and TASKING and their respective logos are trademarks or registered trademarksof Altium Limited or its subsidiaries. All other registered or unregistered trademarks referenced herein are the property oftheir respective owners, and no trademark rights to the same are claimed. Altium assumes no responsibility for any errorsthat may appear in this document.

REFERENCES FOR FURTHER READING

MISRA, Guidelines for the Use of C Language in Vehicle BasedSoftware, Motor Industry Research Association, 1998, ISBN0952415690. http://www.misra.org.uk

Kernighan B.W., Ritchie D.M., The C Programming Language,second edition, Prentice Hall, 1988, ISBN 0131103628.

INTERNETWebsite: www.altium.com/taskingDevelopers’ forum: www.yahoogroups.com/group/TASKINGforumMISRA: www.misra.org.uk

DISTRIBUTOR

misrac

Documents