Hvac Programming Guide - Doc 0

This document and the information ..............................................
Document, in so far as it is based on VDO authorship, are and remain

the property of VDO. This document and ll information is confidential.
The user is not allowed to disclose it to third parties without having the
prior written consent of VDO. All rigths, especially with regard to
inventions, are reserved by VDOTransmittal, reproduction,
dissemination and/or editing of this document as well as utilization of its
contents and communication there of to others without express
authorization are prohibited. Offenders will be held liable for payment of
damages. All rights created by patent grant or registration of a utility
model or design patent are reserved.
HVAC Programming Guideline
HVAC C-Programming Rules

HVAC MISRA Rules
Author:
Designed by
Siemens VDO Automotive AG
Limoa, HVAC
Revision:
1.1
Status:
<released>
File:
344099406.odt
Notes:
The SMK is valid in all matters and specifications that are not described here in detail, unless
a project-specific agreement has been reached, written, reviewed and released in the project
plan.
Sofian.limoa@siemens.com
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
Copyright ( C ) Siemens AG 2003
1 of 181
A4 : 2003-02

Designed by
History
Revision
Date
Author, Editor
Reason
1.0
2003.12.03
Sofian Limoa
initial
1.1
2005.09.21
Leichner, Frank
Freigabe
1.0
1.0
1.0
1.0
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
2 of 181
A4 : 2003-02
Table of Contents
History..............................................................................................................................2
Table of Contents............................................................................................................3
Basic-Set QAC 5.0.1......................................................................................................11
3.1
Basic-Set C Rules..........................................................................................................11
3.1.1
Rule g2.15 | Mandatory..........................................................................................11
QAC-Rules: 0468, 0469, 0808, 0810, 0838, 0839.........................................................11

3.1.2
Rule g2.28 | Mandatory..........................................................................................13
QAC-Rules: 0767, 0769, 3333.......................................................................................13

3.1.3
Rule mr2077 | Mandatory......................................................................................14
QAC-Rules: Logic.........................................................................................................15
3.1.4
QAC-Rules: 0468, 0469.................................................................................................16

3.1.5
QAC-Rule: Logic...........................................................................................................17
3.1.6
Rule r2.01 | Mandatory...........................................................................................17
QAC-Rules: 0346, 0602, 0836, 1300, 1301, 3602, 3615?............................................18

3.1.7
Rule r2.05 | Mandatory...........................................................................................19
QAC-Rules: 0543, 0744, 0745, 0746.............................................................................19

3.1.8
Rule r2.06 | Mandatory...........................................................................................20
QAC-Rules: 0304, 0454, 0775, 2711, 3620...................................................................20

3.1.9
Rule r2.13 | Mandatory...........................................................................................21
QAC-Rules:....................................................................................................................21
3700 3713, 3715, 3717, 3719, 3720 3723, 3725, 3727, 3729, 3730 3736, 3738,
3740 3748, 3750, 3752 3760, 3762 3772, 3774- 3807, 3810 3819, 3821 - 3834,
3837, 3839, 3840, 3843, 3844, 3847, 3848, 3850 - 3881, 3892, 3900 3913, 3915,
3917, 3919 - 3923, 3925, 3927, 3929 - 3936, 3938, 3940 3948, 3950, 3952 - 3960,
3962 3972, 3974 4007, 4010 - 4019, 4021- 4034, 4037, 4039, 4040, 4043, 4044,
4047, 4048, 4050 - 4081.................................................................................................21
3.1.10
Designed by
Rule r2.39 | Mandatory...........................................................................................63
QAC-Rules: 0306, 0307, 0308, 0309, 0310, 0311, 0312, 0313, 0431, 0432, 0488,
0489, 0562, 0563, 0673, 0757, 3003, 3216, 3217, 4140...............................................64
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
3 of 181
A4 : 2003-02

3.1.11
Rule r2.40 | Mandatory...........................................................................................68
QAC-Rules: 3216, 3217, 3225, 3348, 3349, 4140........................................................69

3.1.12
Rule r2.51 | Mandatory...........................................................................................71
QAC-Rules: 3409, 3410, 3411, 3430.............................................................................71

3.1.13
Rule r2.53 | Mandatory...........................................................................................72
QAC-Rules: --.................................................................................................................73
3.1.14
Rule r2-56 | Mandatory..........................................................................................74
QAC-Rules: 1300, 1301.................................................................................................74

3.1.15
Rule r4.11 | Recommended...................................................................................75
3.1.16
Rule r4.2 | Mandatory.............................................................................................75
QAC-Rules:--..................................................................................................................81
3.1.17
Rule SMK502 | Mandatory.....................................................................................81
QAC-Rule: Logic...........................................................................................................82
3.2
Basic-Set Misra..............................................................................................................82
3.2.1
Environment...........................................................................................................82
MISRA Rule 1: All code shall conform to ISO 9899 Standard C, with no extensions
permitted........................................................................................................................82
QAC-Rules: 0180, 0246, 0551, 0601, 0602, 1003, 1006, 1010, 1014, 1018 1022,
1026, 1027, 3664............................................................................................................83
3.2.2
Character Sets........................................................................................................86
MISRA Rule 5: Only those characters and escape sequences which are defined in
the ISO C standard shall be used................................................................................86
QAC-Rules: 0235, 0285-0289........................................................................................89
3.2.3
Comments...............................................................................................................92

MISRA Rule 9: Comments shall not be nested..........................................................92

QAC Rule: 3108.............................................................................................................92
3.2.4
MISRA Rule 11: Identifiers (internal and external) shall not rely on significance of
more than 31 characters. Furthermore the compiler/linker shall be checked to
ensure that 31 character significance and case sensitivity are supported for
external identifiers........................................................................................................92
QAC-Rules: 0777, 0779.................................................................................................93
3.2.5
Designed by
Identifiers................................................................................................................92
Types.......................................................................................................................93
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
4 of 181
A4 : 2003-02

MISRA Rule 14: The type char shall always be declared as unsigned char or
signed char....................................................................................................................93
QAC-Rule 3625..............................................................................................................94
3.2.6
Constants................................................................................................................94
MISRA Rule 19: Octal constants (other than zero) shall not be used.....................94
QAC Rules: 0339, 3628.................................................................................................94
3.2.7
Declaration and Definition, Misra-Rules: 20, 21, 24, 25, 26, 29*........................94
MISRA Rule 20: All object and function identifiers shall be declared before use. 95
QAC-Rule 3335..............................................................................................................95
MISRA Rule 21: Identifiers in an inner scope shall not use the same name as an
identifier in an outer scope, and therefore hide that identifier................................95
QAC-Rules: 2547, 3334.................................................................................................96
MISRA Rule 24: Identifiers shall not simultaneously have both internal and
external linkage in the same translation unit.............................................................97
QAC-Rule 0625..............................................................................................................98
MISRA Rule 25: An identifier with external linkage shall have exactly one external
definition........................................................................................................................98
QAC-Rules 0630, 5025..................................................................................................98
MISRA Rule 26: If objects or functions are declared more than once they shall
have compatible declarations......................................................................................98
QAC-Rules: 0626, 0627, 0628, 5026.............................................................................99
MISRA Rule 29: The use of a tag shall agree with its declaration.........................100
QAC-Rule: 0547...........................................................................................................101

3.2.8
MISRA Rule 32: In an enumerator list, the '=' construct shall not be used to
explicitly initialise members other than the first, unless all items are explicitly
initialised......................................................................................................................101
QAC-Rule 0723............................................................................................................102
3.2.9
Designed by
Initialization..........................................................................................................101
Operators, Misra Rules: 33*, 34, 35, 36, 37*, 42................................................102
MISRA Rule 33*: The right hand operand of a && or || operator shall not contain
side effects..................................................................................................................102
QAC-Rule 3415............................................................................................................103
MISRA Rule 34: The operands of a logical && or || shall be primary expressions.
......................................................................................................................................103
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
5 of 181
A4 : 2003-02

QAC-Rule 3400............................................................................................................103
MISRA Rule 35: Assignment operators shall not be used in expressions which
return Boolean values................................................................................................104
QAC-Rule 3326............................................................................................................104
MISRA Rule 36: Logical operators should not be confused with bitwise operators.
......................................................................................................................................104
QAC Rules: 4101, 4102, 4106 4110..........................................................................105
MISRA Rule 37: Bitwise operations shall not be performed on signed integer
types.............................................................................................................................106
QAC-Rules 0502, 4130, 4131......................................................................................106
MISRA Rule 42: The comma operator shall not be used, except in the control
expression of a for loop.............................................................................................107
QAC-Rules 3417..........................................................................................................108
3.2.10
Conversions.........................................................................................................108
MISRA Rule 45: Type casting from any type to or from pointers shall not be used.
......................................................................................................................................108
QAC-Rules: 0306, 0307, 0308, 0310, 0311, 0312, 3305............................................109
3.2.11
Expressions, Misra-Rules 46, 49, 50..................................................................111
MISRA Rule 46: The value of any expression shall be independent of the order of
its evaluation................................................................................................................111
QAC-Rules: 0400, 0401, 0402, 0403...........................................................................112
MISRA Rule 49: Tests of a value against zero should be made explicit, unless the
operand is effectively Boolean..................................................................................113
QAC-Rule 3344............................................................................................................114

MISRA Rule 50: Floating point variables shall not be tested for exact equality or
inequality......................................................................................................................114
QAC-Rule 3341............................................................................................................115
3.2.12
Designed by
Control Flow, Misra-Rules 53*, 56, 57, 58, 59, 61, 62, 64, 65............................115
MISRA Rule 53: All non-null statements shall have a side-effect..........................115

QAC-Rules: 3110, 3112, 3404, 3425, 3426, 3427.......................................................116
MISRA Rule 56: The goto statement shall not be used...........................................117
QAC-Rule 2001............................................................................................................117
MISRA Rule 57: The continue statement shall not be used...................................117
QAC-Rule 0770............................................................................................................118
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
6 of 181
A4 : 2003-02

MISRA Rule 58: The break statement shall not be used (except to terminate the
cases of a switch statement).....................................................................................118
QAC-Rules: 0769, 3333...............................................................................................119
MISRA Rule 59: The statements forming the body of an if, else if, else, while, do ...
while or for statement shall always be enclosed in braces....................................119
QAC-Rules: 2212, 2214, 3402.....................................................................................120
MISRA Rule 61: Every non-empty case clause in a switch statement shall be
terminated with a break statement............................................................................121
QAC-Rule 2003............................................................................................................122
MISRA Rule 62: All switch statements should contain a final default clause......123
QAC-Rules: 2002, 2009...............................................................................................123
MISRA Rule 64: Every switch statement shall have at least one case..................123
QAC-Rule 3315............................................................................................................124
MISRA Rule 65: Floating point variables shall not be used as loop counters.....124
QAC-Rule 3340............................................................................................................124
3.2.13
Functions, Misra-Rules: 68, 69, 70*, 72, 73, 75, 76, 78, 79, 80, 82, 83, 84.......124
MISRA Rule 68: Functions shall always be declared at file scope........................124

QAC-Rule 3221............................................................................................................125
MISRA Rule 69: Functions with variable numbers of arguments shall not be used.
......................................................................................................................................125
QAC-Rule 5069............................................................................................................125
MISRA Rule 70*: Functions shall not call themselves, either directly or indirectly:
......................................................................................................................................125
QAC-Rules: 3670, 5070...............................................................................................126

MISRA Rule 72: For each function parameter the type given in the declaration and
definition shall be identical, and the return types shall also be identical............126
Designed by
QAC-Rules 1331, 1332, 1333......................................................................................127

MISRA Rule 73: Identifiers shall either be given for all of the parameters in a
function prototype declaration, or for none.............................................................128
QAC-Rule 0652............................................................................................................128
MISRA Rule 75: Every function shall have an explicit return type........................128
QAC-Rule 2050............................................................................................................129
MISRA Rule 76: Functions with no parameters shall be declared with parameter
type void......................................................................................................................129
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
7 of 181
A4 : 2003-02

QAC-Rule 1303............................................................................................................129
MISRA Rule 78: The number of parameters passed to a function shall match the
function prototype......................................................................................................129
QAC-Rules: 0422, 0423, 3319.....................................................................................130
MISRA Rule 79: The values returned by void functions shall not be used..........130
QAC 0543.....................................................................................................................131
MISRA Rule 80: Void expressions shall not be passed as function parameters. 131
QAC 0541.....................................................................................................................131
MISRA Rule 82: A function should have a single point of exit...............................132
QAC-Rule 2006............................................................................................................132
MISRA Rule 83: Functions with non-void return type shall have: i) one return
statement for every exit branch (including the end of the program), ii) each return
shall have an expression, iii) the expression shall match the return type...........132
QAC-Rules: 0744, 0745, 1403, 1413, 1423, 1433, 1443, 3900 3913, 3915, 3917,
3919 - 3923, 3925, 3927, 3929 3936, 3938, 3940 3948, 3950, 3952 3960, 3962
3972, 3974 4007, 4010 4019, 4021 4034, 4037, 4039, 4040, 4043, 4047, 4048,
4050 4081..................................................................................................................133
MISRA Rule 84: For functions with void return type, return statements shall not
have an expression.....................................................................................................162
QAC-Rule 0746............................................................................................................162
3.2.14
Preprocessing Directives, Misra-Rules: 88, 89, 91, 94, 95, 96, 98, 99, 100....163
MISRA Rule 88: Non-standard characters shall not occur in header file names in
#include directives......................................................................................................163
QAC-Rules 0813, 0814, 0831......................................................................................163
MISRA Rule 89: The #include directive shall be followed by either a <filename> or
"filename" sequence..................................................................................................163
QAC-Rules: 0809, 0832...............................................................................................164
Designed by
MISRA Rule 91: Macros shall not be #define'd and #undef'd within a block.......164
QAC-Rule 0842............................................................................................................164
MISRA Rule 94: A function-like macro shall not be 'called' without all of its
arguments....................................................................................................................165
QAC-Rules: 0850, 0856...............................................................................................165
MISRA Rule 95: Arguments to a function-like macro shall not contain tokens that
look like pre-processing directives...........................................................................165
QAC-Rule 0853............................................................................................................166
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
8 of 181
A4 : 2003-02

MISRA Rule 96: In the definition of a function-like macro the whole definition, and
each instance of a parameter, shall be enclosed in parentheses.........................166
QAC Rules: 3409, 3410...............................................................................................166
MISRA Rule 98: There shall be at most one occurrence of the # or ## preprocessor operators in a single macro definition...................................................167
QAC-Rules: 0880, 0881...............................................................................................167
MISRA Rule 99: All uses of the #pragma directive shall be documented and
explained......................................................................................................................168
QAC-Rule 3116............................................................................................................168
MISRA Rule 100: The defined pre-processor operator shall only be used in one of
the two standard forms..............................................................................................168
QAC 0887, 0888...........................................................................................................168
3.2.15
Pointers and Arrays, Misra-Rule: 106*...............................................................169
MISRA Rule 106: The address of an object with automatic storage shall not be
assigned to an object which may persist after the object has ceased to exist.. .169
QAC-Rules: 3216, 3217, 3225, 4140...........................................................................169
3.2.16
Structures and Unions, Misra-Rules: 108, 109, 110, 113..................................170
MISRA Rule 108: In the specification of a structure or union type, all members of
the structure or union shall be fully specified.........................................................170
QAC-Rules: 0554, 0545, 0623, 0636, 3310, 3313......................................................170
MISRA Rule 109: Overlapping variable storage shall not be used........................171
No QAC messages cover this rule............................................................................171
MISRA Rule 110: Unions shall not be used to access the sub-parts of larger data
types.............................................................................................................................172

QAC-Rules: 0750, 5110...............................................................................................172

MISRA Rule 113: All the members of a structure (or union) shall be named and
shall only be accessed via their name......................................................................172
QAC-Rules: 0660, 3663...............................................................................................172
3.2.17 Standard Libraries, Misra-Rules: 114, 115, 118, 119, 120, 121, 122, 123, 124,
125, 126, 127........................................................................................................................173
Designed by
MISRA Rule 114: Reserved words and standard library function names shall not
be redefined or undefined..........................................................................................173
QAC-Rules: 0836, 0848, 0854, 5114...........................................................................173
MISRA Rule 115: Standard library function names shall not be reused...............174
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
9 of 181
A4 : 2003-02

QAC-Rules: 0602, 5115...............................................................................................174
MISRA Rule 118: Dynamic heap memory allocation shall not be used................175
QAC-rule: 5115............................................................................................................175
MISRA Rule 119: The error indicator errno shall not be used...............................175
QAC-Rule: 5119...........................................................................................................176
MISRA Rule 120: The macro offsetof, in library <stddef.h>, shall not be used.. .176
QAC-Rule: 5120...........................................................................................................176
MISRA Rule 121: <locale.h> and the setlocale function shall not be used..........176
QAC-Rule 5121............................................................................................................176
MISRA Rule 122: The setjmp macro and the longjmp function shall not be used.
......................................................................................................................................176
QAC-Rule 5122............................................................................................................177
MISRA Rule 123: The signal handling facilities of <signal.h> shall not be used.177
QAC-Rule: 5123...........................................................................................................177
MISRA Rule 124: The input/output library <stdio.h> shall not be used in
production code..........................................................................................................177
QAC-Rule 5124............................................................................................................178
MISRA Rule 125: The library functions atof(), atoi() and atol() from library
<stdlib.h> shall not be used.......................................................................................178
QAC-Rule 5125............................................................................................................178
MISRA Rule 126: The library functions abort(), exit(), getenv() and system() from
library <stdlib.h> shall not be used..........................................................................178
QAC-Rule 5126............................................................................................................179

MISRA Rule 127: The time handling functions of library <time.h> shall not be
used..............................................................................................................................179
3.3
Designed by
QAC-Rule 5127............................................................................................................179
QAC-Set Metrics..........................................................................................................179
QAC 4700.....................................................................................................................179
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
10 of 181
A4 : 2003-02
Basic-Set QAC 5.0.1
This QAC-Basic-Set Guide gives you the information about Basic-Set C, Basic-Set Misra, Basic-Set Metrics
(Product-Metrics) Rules which are integrated in QAC 5.0.1 tools.
3.1
Basic-Set C Rules
3.1.1
Rule g2.15 | Mandatory
All header files should be protected against multiple inclusion (include guards) to speedup compilation.
Justification
If headers contain definitions (they should only contain declarations), include guards protect against multiple
definitions within same compiltion unit. Using include guards reduces compile time and protects against endless
recursive inclusion. In environments with many header files and excessive compile time, one should consider
using both, internal and external, include guards.
Example
Include guards do not protect against multiple definition across compilation units, still causing a linker
error (except for definitions of common variables) .
External include guards are more effective in reducing compile time than internal include guards.
/* File Name: aioa1c1.h */
/* protect against multiple inclusion using an internal include guard: */

#ifndef AIOA_C1_H
#define AIOA_C1_H
...
#endif
/* end of file */
/* file aioa1c1.c : */
/* protect against multiple inclusion using an external include guard:
*/
#ifndef AIOA_C1_H
#include <aioa1c1.h>
#endif

QAC-Rules: 0468, 0469, 0808, 0810, 0838, 0839

0468
Constraint
[C] Unary '-' requires arithmetic operand.
This warning is produced because you are using the unary '-' operator on an operand which does not have
arithmetic type. Please check your declaration of the operand. e.g.
struct s { int x; };
int val;
struct s field;
val = -field;
Designed by
/* field is not of arithmetic type */
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
11 of 181
A4 : 2003-02

0469
Constraint
[C] Bitwise not '~' requires integral operand.
The unary '~' operator can only be applied to operands with integral type. Check the declaration of the operand.
e.g.
int val;
struct s field;
val = ~field;
produces the same warning.

integral type - the set of all types whose value can be represented by a pure binary numeration system. In C the
types of char, signed and unsigned integer and enumerated are considered integral types.
0808
Config
'#include "%s"' causes itself to be included recursively. QA C ignores it after 8

occurrences.
You have constructed a header file which directly or indirectly includes itself. In the example below the file will be
recursively included indefinitely. QA C terminates recursive inclusion after 8 occurrences. In the example below
the recursion could be prevented by placing the #ifndef _INC_THIS and #define _INC_THIS guard at the top of
the file, i.e. before the #include __FILE__.
#include __FILE__
#ifndef _INC_THIS
#define _INC_THIS
static float fn(int a)
{
return a-(a/a);
}
#endif
0810
ISO_Limits
[L] '#include "%s"' causes nesting to exceed 8 levels - program is nonconforming.

The ISO standard requires that the depth of nesting of conditional inclusion be 8 levels. QAC takes the view that
up to 8 levels can therefore be guaranteed to be handled correctly by any conforming compiler, but that support
for further levels is compiler dependent and hence use of further levels is non-portable.
0838
Min_Prepro
File has already been included at top level.
This message is generated when a file is included twice from the top (i.e. source file) level. This is bad practice
and probably a mistake. For example:
#include "test.h"
/* lots of other includes ... */
#include "test.h"
Designed by
/* included again? */
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
12 of 181
A4 : 2003-02

0839
Min_Prepro
File was included from within a previous include.
The message is generated if the same file is included more than once within your source code. This rule is only
applied if the statement is of the form:
#include "xxxx.h"
It will not be generated for system headers included with a statement of the form:
#include
3.1.2 Rule g2.28 | Mandatory

The break statement shall not be used, other than to end a case in a switch statement.
Justification
Like in functions, limiting the number of exit points in loops to 1 usually leads to a more simple code structure.
Example
None
QAC-Rules: 0767, 0769, 3333
0767
Constraint
[C] 'break' statement found outside a loop or 'switch' statement.
A 'break' statement should only be present in a 'switch' statement as it terminates execution of the enclosing
statement. e.g.
static int
func1(void)
{
int i = 0;
int j = 0;
if( i && j)
{
break;
}
else
{
break;
/* message 0767 */
}
}
0769
Min_Ctrl
A break statement shall only be used in a switch statement.

It is good style to avoid 'break' statements as far as possible except in switch statements. Programming
standards often include this recommendation. Message 769 will be generated whenever a break statement is
encountered within a loop statement but outside a switch statement.
For example:
while (gi != 0)
{
gi++;
if (gi == VALUE)
{
break;
/* Message 769 */
}
}
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
13 of 181
A4 : 2003-02

3333
Min_Ctrl
A break statement shall only be used at the end of all the statements in a switch
case block.
Break statements should be avoided as far as possible except in switch statements. Any break in control flow
increases complexity which can affect maintainability and reliability. A 'break' can usually be avoided - perhaps by
making the loop termination condition dependent upon a continuation flag. Message 3333 is functionally similar to
message 769 - but is generated only in the context of an if statement within a switch construct..
For example:
switch(n)
{
case 1:
if (flag == 0)
break;
/* Message 3333 */
...
break;
case 2:
...
3.1.3 Rule mr2077 | Mandatory

The use of synonym adaptations should be avoided as much as possible. This implies:
Synonym adaptations are not allowed outside of CI headers.
Every synonmym must be commented, explaining, why the synonym adaptation is required.
Synonym adaptations of variables are forbidden because of information hiding!
Synonym adaptations of functions must have identical parameter lists.
Functions, which are subject to permanent configuration by synonym adaptations, must have
the prefix SYN_ instead of the module name (Use 1 underscore to illustrate the external
dependency).
Justification
Synonym adaptations make the code extremely hard to read and to debug, because what you see is not what
you get! Therefore synonym adaptations are restricted to module internal configuration and should be considered
as temporary solutions only, e.g. for test purposes.
Tip: to guarantee that with "i = function(1,2,3)" function is a function and not a macro, you can do the following:
use brackets: i = (function)(1,2,3). Even if you #define function(a,b,c), the preprocessor will not
apply this definition.
#undef function before using it.
Example
1. Bad example

#define TCVEL__wGetSpeed() VEL_wGetVelocity (2,3)

...
TCVEL__funca()
a = TCVEL__wGetSpeed();
/* Confusing, because actually this line says

/*
/*
/*
/*
*/
a = VEL_wGetVelocity(2,3),
*/
which is hidden from the user.
*/
Better: change the function name in the code or */
use the convention in example 3
*/
...
2. Testexample
#define TCVEL__wGetSpeed() 5
...
TCVEL__funca()
Designed by
/* Teststub for Testcase xyz - will be deleted after test */
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
14 of 181
A4 : 2003-02

{
wVelocity = TCVEL__wGetSpeed();
/*
/*
/*
/*
After finishing the test, the

adaptation will be deleted,
and the internal function
TCVEL__wGetSpeed will be used - ok
*/
*/
*/
*/
...
3. Configurationexample
#if (PROJ==A)
#define SYN_wGetSpeed() VEL_wGetVel()
/* Different function name in

*/
/* project A, because not the standard */
/* NXDA function is used
*/
#else
#define SYN_wGetSpeed() NXD_wGetSpeed() /* In all other projects, the data is */
/* fetched from the norming layer NXDA */
#endif
...
TCVEL__funca()
{
wVelocity = SYN_wGetSpeed();
/* This function will be overwritten by */
/* a synonym adaptation in the CI Header */
/* Obvious thanks to the SYN prefix
*/
...
QAC-Rules: Logic
Using unary operators in comparison expressions often will lead to unexpected behaviour. Unary operators in
expressions therefore always must be explicitly casted.
Justification
An unary operator (e.g. "~", "-") is an operation of itself and will typically lead to an unmasked promotion
operation inside the register.
Example
uint8 u8_v1;
uint8 u8_v2;
u8_v1 = ~0xff;
// The result is 0:
// 1. 0x00ff is stored in a register
// 2. inverted leading to 0xff00
// 3. and uint8 casted (assigned to an 8bit variable), leading to 0x0000
u8_v2 = 0xff;

if (u8_v1 == ~0xff)
{
// Is this part executed?
// Usually not, because on register level the following happens:
// 1. 0x00ff is stored, negated resulting in 0xff00
// 2. and NOT casted.
// Compared with 0x0000, the result is false
}
// what about
if (u8_v1 == ~u8_v2)
{
// Same procedure as above
}
// The correct code:
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
15 of 181
A4 : 2003-02

if (u8_v1 == (uint8)~u8_v2)
QAC-Rules: 0468, 0469

0468
Constraint
[C] Unary '-' requires arithmetic operand.
This warning is produced because you are using the unary '-' operator on an operand which does not have
arithmetic type. Please check your declaration of the operand. e.g.
int val;
struct s field;
val = -field;
0469
/* field is not of arithmetic type */
Constraint
[C] Bitwise not '~' requires integral operand.
The unary '~' operator can only be applied to operands with integral type. Check the declaration of the operand.
e.g.
int val;
struct s field;
val = ~field;
produces the same warning.

integral type - the set of all types whose value can be represented by a pure binary numeration system. In C the
types of char, signed and unsigned integer and enumerated are considered integral types.
When intermixing C and Assembly code, all registers used by the assembly section must be saved before use
and restored afterwards.

Justification
The calling conventions of a compiler differentiate between specific caller and callee saved registers. Caller
saved registers are those registers, which are saved by the caller of a function and which are often used for
parameter passing. Callee saved registers must be saved by the function using them, e.g. by storing the contents
on the stack and restoring them when leaving the function. When using only C functions, all this is handled by the
compiler.
When intermixing C and assembly code, the callee saved registers must be stored manually. When writing
assembly IRQ routines, typically all registers must be saved before being used. Bugs based on missing saving of
registers will lead to hard to find data inconsistencies with typically fatal impact on the system.
As the calling conventions differ between compilers, special care must be taken when porting code from one
compiler to another.
Example
The following example shows the principle call of an assembler subroutine in pseudo code
// C caller
erg = AssemblerFunction(1,2);
// Assembly Callee
#pragma ASM
// R1, R2 are by convention caller saved and contain the parameters
// R0 is caller saved and contains the return value
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
16 of 181
A4 : 2003-02

// R3 which contains
.AssemblerFunction
PUSH R3
ADD R3, R1, R2
MOV R3, R0
POP R3
the result is callee saved and must be saved before use

//
//
//
//
Save R3 on the stack

Calculate the sum of R1 and R2
Pass the result to the return value
Restore R3
When defining an IRQ function, typically no registers are saved automatically by the compiler. Instead, all
registers must be saved manually. Never rely on the assumption, that the registers have not been used before
the IRQ!
.pragma ASM
.IRQFunction
// R1, R2 are used and therefore are stored on the stack
PUSH R1, R2
MOV #2 R1
MOV #4, R2
....
POP R1, R2
// Store the contents on the stack

// Use them savely
// Restore the contents
Using Inline Assembly is a similar situation like IRQ routines. Calling conventions are not relevant, but instead, all
registers must be saved before being used. Again, as it is completely undefined which parameters have been
used for parameter storage in the C section before, data cannot be passed between the C and assembly section.
void CFunction();
{
int b; // Stored by coincidence in R1
b = CanStatus();
InlineASM(
// R2 and R3 are used and saved on the stack
PUSH R2, R3
....
ADD R2, R1, #2
// Intention : R2 = b+2
// A minor change in the application (e.g. in CanStatus,
// Compile options,...) however will result in b
// to be stored in a different register
// resulting in a wrong calculation and data corruption of R1
...
)
}
QAC-Rule: Logic

3.1.6 Rule r2.01 | Mandatory

Identifiers reserved by Standard C must not be reused.
Justification
This leads to undefined behavior. Redefining functions from the C standard libraries may lead to confusion and
unexpected behaviour.
Example
ANSI C reserves identifiers beginning with underline.
Xint _STDC_ =0; /* Trouble!
/* Some compilers will not complain. Others might.
/* Linkers may be confused and your fellow developers, too
Note:
Designed by
*/
*/
*/
For historical reasons, bitfield types from cdef.h (bit8 and bit16) are a exception to this rule.
They provide bit identifiers _0 .. _15.
Standard C also includes Standard C libraries. They define the following standard functions:
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
17 of 181
A4 : 2003-02

abort, abs, acos, asctime, asin, atan, atan2, atexit, atof, atoi, atol, bsearch, ceil, calloc, clearerr, clock, cos, cosh,
ctime, difftime, div, exit, exp, fabs, fclose, feof, ferror, fflush, fgetc, fgetpos, fgets, floor, fmod, fopen, fprintf, fputc,
fputs, fread, free, freopen, frexp, fscanf, fsetpos, ftell, fwrite, getc, getchar, getenv, gets, gmtime, isalnum, isalpha,
iscntrl, isdigit, isgraph, islower, isprint, ispunct, isspace, isupper, isxdigit, labs, ldexp, ldiv, localeconv, localtime,
log, log10, longjmp, malloc, mblen, mbstowcs, mbtowc, memchr, memcmp, memcpy, memmove, memset,
mktime, modf, perror, printf, putc, putchar, puts, qsort, raise, rand, realloc, remove, rename, rewind, scanf, setbuf,
setlocale, setvbuf, sin, sprintf, sqrt, srand, strcmp, sscanf, strcat, strchr, strcoll, strcopy, strcspn, strerror, strftime,
strlen, strncat, strncmp, strncpy, strpbrk, strrchr, strspn, strstr, strtod, strtok, strtol, strtoul, strxfrm, system, tan,
tanh, time, tmpfile, tmpnam, tolower, toupper, ungetc, vfprintf, vprintf, vsprintf, wcstombs, wctomb
If custom implementations are needed (e.g. for optimization reasons), they must behave like the standard
implementation.
QAC-Rules: 0346, 0602, 0836, 1300, 1301, 3602, 3615?
0346
Min_KandR
'%s' is an ISO keyword and will not be recognised by K&R compilers.
This is not portable to K&R compilers. Macros can be used to map keywords to nothing.
Non-portable keywords include const, signed, and volatile
0602
ISO_ExpU
[U] The identifier '%s' is reserved for use by the library.
This identifier is a reserved identifier and should not be used here. e.g.
int
main (void)
{
int __sigDefault;
int __sigIgnore;
int __sigError;
int _sigIgnore;
return 1;
/*
/*
/*
/*
warning 0602:
*/
prefix '__' reserved */
for library use
*/
OK */
}
0836
ISO_ExpU
[U] Definition of macro named 'defined'.
You have attempted to #define a macro called 'defined'. The word 'defined' is a preprocessor operator and it
should never be redefined or undefined. e.g.
#define defined "defined"
/* illegal */
'defined' is a reserved operator introduced to test for the presence of macro definitions.
It evaluates to 1 if its identifier operand is currently defined as a macro name and to 0 if it is not.
1300
Min_Cpp
'%s' is a keyword in C++.

The specified identifier is a recognised C++ keyword. This will normally result in a syntax violation when trying to
compile using a C++ compiler.
...
int class;
...
'class' is a C++ keyword - avoid using names which duplicate

1301
Min_Cpp
'%s' is a keyword in some C++ implementations.
This keyword is an anachronism in C++ but is still supported by many compilers. e.g.
int overload; /* warning 1301 - may be a keyword: */
3602
Designed by
Min_KandR
The keyword '%s' is not available in K&R C.
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
18 of 181
A4 : 2003-02

This keyword was added in ANSI C. This code will not be portable to older compilers.
The following keywords are not available in K&R C, although available in ANSI C:
const
signed
void
volatile
enum
3615
Min_KandR
'entry' was a keyword in K&R C.
The keyword 'entry' was reserved in K&R C.

Do not try to evaluate void expressions (neither as result of a function returning void, nor otherwise)
Justification
The result is (naturally) undefined. A common source of error are changes in function interfaces that lead to the
evaluation of void expressions - giving unpredictable results.
Example
void f(); int i=(int) f(); /* undefined !
* f() is evaluated for its side effects.
*/
QAC-Rules: 0543, 0744, 0745, 0746

0543
ISO_ExpU
[U] 'void' expressions have no value and may not be used in expressions.
The (nonexistent) value of an expression of type void cannot be used in any way, and implicit or explicit
conversions (except to void) cannot be applied to such an expression. For example:
extern void foo(void);
...
if ( foo( ) == 0)
{
...
0744
/* Message 543 */
ISO_ExpU
[U] '%s()' has been declared with a non void result type but ends with an implicit
'return ;' statement.
This function has been explicitly defined as having a non-void return type but ends with an implicit return
statement which returns no value. This will always return an undefined value. e.g.

float func(void)
{
/* no return statement */
}
0745
ISO_ExpU
[U] 'return;' found in '%s()', which has been defined with a non-'void' return type.
This return statement has no return expression although a non-void return type for the function has been defined.
The value returned by the function is undefined. e.g.
float func(void)
{
/* ... */
return;
}
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
19 of 181
A4 : 2003-02

0746
Constraint
[C] 'return exp;' found in '%s()' whose result type is 'void'.
The ISO standard forbids the presence of a return statement (with a return expression) in a function whose return
type is 'void'. e.g.
void func(void)
{
int i;
/* ... */
return i;
/* illegal */
}

The address of a variable declared register shall not be used.
Justification
Registers do not have adresses. Adressing register variables is not allowed acording to ANSI C (1990).
Example
Sometimes developers try to write more performant code by declaring an array register. Note that no pointer
arithmetic is possible on such arrays, since they are not located in normal storage.
register int arr[MX_SIZE];
int* arr_ptr;
arr_ptr=arr; /* This is not allowed!
* Where will arr_ptr point to physically?
*/
QAC-Rules: 0304, 0454, 0775, 2711, 3620

0304
ISO_ExpU
[U] The address of an array declared 'register' may not be computed.
Arrays declared with the 'register' storage class specifier should be considered as having no physical address
(although a particular implementation could treat a register declaration as being an auto declaration).
If an array has no computable address then it is illegal to try to take the address either implicitly (through the
conversion of an array name to a pointer) or explicitly with the unary '&' operator. e.g.
register int array[10];
int * ptr = array;
/* probably illegal */
0454
Constraint
[C] The address-of operator '&' cannot be applied to an object declared with
'register'.

In compiled code, when the register hint is given to the compiler, the address of the variable cannot be requested.
For example:
static void foo (void)
{
register int a;
int *pa;
pa = &a;
/* cannot apply to 'register' declaration */
0775
Constraint
[C] '%s': 'register' may not be specified for global declaration.
The 'register' storage class specifier has been applied to a global declaration (with internal or external linkage).
The 'register' specifier can only be used on declarations with function/block scope. e.g.
register int number;
/* illegal at file scope */
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
20 of 181
A4 : 2003-02
2711
Min_Decl
'register' is only a hint - the compiler may well be able to do a better job of
optimising - avoid!
Use of the keyword register is no longer needed. Most modern compilers will optimise variables into registers
doing a better job of optimisation than a programmer could. It is best to avoid using the keyword register.
void
fn(void)
{
register int i;
/* ... */
}
/* 'register' only a compiler hint*/
Better to remove the 'register' storage-class specifier.

3620
Maj_Decl
'register' may be illegal on array and 'struct' / 'union' types in some compilers.
This is legal in the ISO standard but some compilers may complain.

Values shall not be implicitly converted to a narrower type, or wrapped around.
Justification
Implicit conversions often escape inspections and have led to some extremely expensive failures.
Example
short
int
float
double
s;
i;
f;
d;
...
s=i;
f=d;
/* potential for information loss */

/* potential for information loss */
/* if it is guaranteed that all legal values for "i" in this context will
* fit into s do an explicit cast and comment it:
*/
s=(short)i; /* i will not be greater than 20; no info loss */
In some cases this highlights a previously unknown problem but in the majority of cases the assignment is
intended as the programmer knows that the value is within the range of the smaller type.
However, any implicit action is forbidden in favour of an explicit action which indicates clearly that the author
intended this situation.
QAC-Rules:
3700 3713, 3715, 3717, 3719, 3720 3723, 3725, 3727, 3729, 3730 3736, 3738, 3740 3748, 3750, 3752
3760, 3762 3772, 3774- 3807, 3810 3819, 3821 - 3834, 3837, 3839, 3840, 3843, 3844, 3847, 3848, 3850 3881, 3892, 3900 3913, 3915, 3917, 3919 - 3923, 3925, 3927, 3929 - 3936, 3938, 3940 3948, 3950, 3952 3960, 3962 3972, 3974 4007, 4010 - 4019, 4021- 4034, 4037, 4039, 4040, 4043, 4044, 4047, 4048, 4050 4081
3700
Maj_Pchar
Implicit conversion: char to signed char.
An object of type char is being implicitly cast to a signed char.

Implicit casts should be avoided.
The result of a conversion to or from a plain 'char' datatype will depend on whether the plain 'char' datatype is
signed or unsigned. This is implementation defined behaviour and it is not wise to make any assumptions.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
21 of 181
A4 : 2003-02

It is safer not to mix 'char' types in expressions.
3701
Maj_Pchar
Implicit conversion: char to unsigned char.
An object of type char is being implicitly cast to an unsigned char.

3702
Maj_Pchar
Implicit conversion: char to short.
An object of type char is being implicitly cast to a short.

3703
Maj_Pchar
Implicit conversion: char to unsigned short.
An object of type char is being implicitly cast to an unsigned short.

3704
Maj_Pchar
Implicit conversion: char to int.
An object of type char is being implicitly cast to a int.

3705
Maj_Pchar
Implicit conversion: char to unsigned int.
An object of type char is being implicitly cast to an unsigned int.

3706
Maj_Pchar
Implicit conversion: char to long.
An object of type char is being implicitly cast to a long.

3707
Maj_Pchar
Implicit conversion: char to unsigned long.

An object of type char is being implicitly cast to an unsigned long.

3708
Maj_Pchar
Implicit conversion: char to float.
An object of type char is being implicitly cast to a float.

There may be a loss of precision here.
3709
Maj_Pchar
Implicit conversion: char to double.
An object of type char is being implicitly cast to a double.

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
22 of 181
A4 : 2003-02
3710
Maj_Pchar
Implicit conversion: char to long double.
An object of type char is being implicitly cast to a long double.

3711
Maj_Pchar
Implicit conversion: unsigned char to char.
An object of type unsigned char is being implicitly cast to a char.

3712
Maj_UStoS
Implicit conversion: unsigned char to signed char.
An object of type unsigned char is being implicitly cast to a signed char.

An unsigned value is being converted to a signed type - the result may be negative.
3713
Maj_UStoLS
Implicit conversion: unsigned char to short.
An object of type unsigned char is being implicitly cast to a short.

3715
Maj_UStoLS
Implicit conversion: unsigned char to int.
An object of type unsigned char is being implicitly cast to a int.

3717
Maj_UStoLS
Implicit conversion: unsigned char to long.
An object of type unsigned char is being implicitly cast to a long.

3719
Maj_ItoFL
Implicit conversion: unsigned char to float.
An object of type unsigned char is being implicitly cast to a float.

3720
Maj_ItoFL
Implicit conversion: unsigned char to double.

An object of type unsigned char is being implicitly cast to a double.

3721
Maj_ItoFL
Implicit conversion: unsigned char to long double.
An object of type unsigned char is being implicitly cast to a long double.

3722
Maj_Pchar
Implicit conversion: signed char to char.
An object of type signed char is being implicitly cast to a char.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
23 of 181
A4 : 2003-02

3723
Maj_StoUS
Implicit conversion: signed char to unsigned char.
An object of type signed char is being implicitly cast to an unsigned char.

A signed datatype is being converted to an unsigned datatype and negative values will be converted to large
positive values.
3725
Maj_StoUS
Implicit conversion: signed char to unsigned short.
An object of type signed char is being implicitly cast to an unsigned short.

positive values.
3727
Maj_StoUS
Implicit conversion: signed char to unsigned int.
An object of type signed char is being implicitly cast to an unsigned int.

positive values.
3729
Maj_StoUS
Implicit conversion: signed char to unsigned long.
An object of type signed char is being implicitly cast to an unsigned long.

positive values.
3730
Maj_ItoFL
Implicit conversion: signed char to float.
An object of type signed char is being implicitly cast to a float.

3731
Maj_ItoFL
Implicit conversion: signed char to double.

An object of type signed char is being implicitly cast to a double.

3732
Maj_ItoFL
Implicit conversion: signed char to long double.
An object of type signed char is being implicitly cast to a long double.

3733
Maj_Pchar
Implicit conversion: short to char.
An object of type short is being implicitly cast to a char.

Data is being converted to a smaller datatype. This may result in a loss of information
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
24 of 181
A4 : 2003-02

3734
Maj_Small
Implicit conversion: short to signed char.
An object of type short is being implicitly cast to a signed char.

3735
Maj_StoUS
Implicit conversion: short to unsigned char.
An object of type short is being implicitly cast to an unsigned char.

positive values.
3736
Maj_StoUS
Implicit conversion: short to unsigned short.
An object of type short is being implicitly cast to an unsigned short.

positive values.
3738
Maj_StoUS
Implicit conversion: short to unsigned int.
An object of type short is being implicitly cast to an unsigned int.

positive values.
3740
Maj_StoUS
Implicit conversion: short to unsigned long.
An object of type short is being implicitly cast to an unsigned long.

positive values.
3741
Maj_ItoFL
Implicit conversion: short to float.

An object of type short is being implicitly cast to a float.

3742
Maj_ItoFL
Implicit conversion: short to double.
An object of type short is being implicitly cast to a double.

3743
Maj_ItoFL
Implicit conversion: short to long double.
An object of type short is being implicitly cast to a long double.

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
25 of 181
A4 : 2003-02

3744
Maj_Pchar
Implicit conversion: unsigned short to char.
An object of type unsigned short is being implicitly cast to a char.

Implicit casts should be avoided. Data is being converted to a smaller datatype. This may result in a loss of
information.
3745
Maj_UStoS
Implicit conversion: unsigned short to signed char.
An object of type unsigned short is being implicitly cast to a signed char.

3746
Maj_Small
Implicit conversion: unsigned short to unsigned char.
An object of type unsigned short is being implicitly cast to an unsigned char.

3747
Maj_UStoS
Implicit conversion: unsigned short to short.
An object of type unsigned short is being implicitly cast to a short.

3748
Maj_UStoLS
Implicit conversion: unsigned short to int.
An object of type unsigned short is being implicitly cast to a int.

3750
Maj_UStoLS
Implicit conversion: unsigned short to long.
An object of type unsigned short is being implicitly cast to a long.

3752
Maj_ItoFL
Implicit conversion: unsigned short to float.
An object of type unsigned short is being implicitly cast to a float.

3753
Maj_ItoFL
Implicit conversion: unsigned short to double.

An object of type unsigned short is being implicitly cast to a double.

3754
Maj_ItoFL
Implicit conversion: unsigned short to long double.
An object of type unsigned short is being implicitly cast to a long double.

3755
Maj_Pchar
Implicit conversion: int to char.
An object of type int is being implicitly cast to a char.

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
26 of 181
A4 : 2003-02

3756
Maj_Small
Implicit conversion: int to signed char.
An object of type int is being implicitly cast to a signed char.

3757
Maj_StoUS
Implicit conversion: int to unsigned char.
An object of type int is being implicitly cast to an unsigned char.

positive values.
3758
Maj_Small
Implicit conversion: int to short.
An object of type int is being implicitly cast to a short.

Data is being converted to a smaller datatype. This may result in a loss of information.
3759
Maj_StoUS
Implicit conversion: int to unsigned short.
An object of type int is being implicitly cast to an unsigned short.

positive values.
3760
Maj_StoUS
Implicit conversion: int to unsigned int.
An object of type int is being implicitly cast to an unsigned int.

positive values.
3762
Maj_StoUS
Implicit conversion: int to unsigned long.

An object of type int is being implicitly cast to an unsigned long.

positive values.
3763
Maj_ItoFL
Implicit conversion: int to float.
An object of type int is being implicitly cast to a float.

3764
Maj_ItoFL
Implicit conversion: int to double.
An object of type int is being implicitly cast to a double.

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
27 of 181
A4 : 2003-02
3765
Maj_ItoFL
Implicit conversion: int to long double.
An object of type int is being implicitly cast to a long double.

3766
Maj_Pchar
Implicit conversion: unsigned int to char.
An object of type unsigned int is being implicitly cast to a char.

3767
Maj_UStoS
Implicit conversion: unsigned int to signed char.
An object of type unsigned int is being implicitly cast to a signed char.

3768
Maj_Small
Implicit conversion: unsigned int to unsigned char.
An object of type unsigned int is being implicitly cast to an unsigned char.

3769
Maj_UStoS
Implicit conversion: unsigned int to short.
An object of type unsigned int is being implicitly cast to a short.

3770
Maj_Small
Implicit conversion: unsigned int to unsigned short.
An object of type unsigned int is being implicitly cast to an unsigned short.

3771
Maj_UStoS
Implicit conversion: unsigned int to int.

An object of type unsigned int is being implicitly cast to a int.

3772
Maj_UStoLS
Implicit conversion: unsigned int to long.
An object of type unsigned int is being implicitly cast to a long.

3774
Maj_ItoFL
Implicit conversion: unsigned int to float.
An object of type unsigned int is being implicitly cast to a float.

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
28 of 181
A4 : 2003-02
3775
Maj_ItoFL
Implicit conversion: unsigned int to double.
An object of type unsigned int is being implicitly cast to a double.

3776
Maj_ItoFL
Implicit conversion: unsigned int to long double.
An object of type unsigned int is being implicitly cast to a long double.

3777
Maj_Pchar
Implicit conversion: long to char.
An object of type long is being implicitly cast to a char.

3778
Maj_Small
Implicit conversion: long to signed char.
An object of type long is being implicitly cast to a signed char.

3779
Maj_StoUS
Implicit conversion: long to unsigned char.
An object of type long is being implicitly cast to an unsigned char.

positive values.
3780
Maj_Small
Implicit conversion: long to short.
An object of type long is being implicitly cast to a short.

3781
Maj_StoUS
Implicit conversion: long to unsigned short.

An object of type long is being implicitly cast to an unsigned short.

positive values.
3782
Maj_Small
Implicit conversion: long to int.
An object of type long is being implicitly cast to a int.

Data is being converted to a smaller datatype. This may result in a loss of information.
3783
Designed by
Maj_StoUS
Implicit conversion: long to unsigned int.
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
29 of 181
A4 : 2003-02

An object of type long is being implicitly cast to an unsigned int.
positive values.
3784
Maj_StoUS
Implicit conversion: long to unsigned long.
An object of type long is being implicitly cast to an unsigned long.

positive values.
3785
Maj_ItoFL
Implicit conversion: long to float.
An object of type long is being implicitly cast to a float.

3786
Maj_ItoFL
Implicit conversion: long to double.
An object of type long is being implicitly cast to a double.

3787
Maj_ItoFL
Implicit conversion: long to long double.
An object of type long is being implicitly cast to a long double.

3788
Maj_Pchar
Implicit conversion: unsigned long to char.
An object of type unsigned long is being implicitly cast to a char.

3789
Maj_UStoS
Implicit conversion: unsigned long to signed char.

An object of type unsigned long is being implicitly cast to a signed char.

3790
Maj_Small
Implicit conversion: unsigned long to unsigned char.
An object of type unsigned long is being implicitly cast to an unsigned char.

3791
Maj_UStoS
Implicit conversion: unsigned long to short.
An object of type unsigned long is being implicitly cast to a short.

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
30 of 181
A4 : 2003-02

3792
Maj_Small
Implicit conversion: unsigned long to unsigned short.
An object of type unsigned long is being implicitly cast to an unsigned short.

3793
Maj_UStoS
Implicit conversion: unsigned long to int.
An object of type unsigned long is being implicitly cast to an int.

3794
Maj_Small
Implicit conversion: unsigned long to unsigned int.
An object of type unsigned long is being implicitly cast to an unsigned int.

3795
Maj_UStoS
Implicit conversion: unsigned long to long.
An object of type unsigned long is being implicitly cast to a long.

3796
Maj_ItoFL
Implicit conversion: unsigned long to float.
An object of type unsigned long is being implicitly cast to a float.

3797
Maj_ItoFL
Implicit conversion: unsigned long to double.
An object of type unsigned long is being implicitly cast to a double.

3798
Maj_ItoFL
Implicit conversion: unsigned long to long double.

An object of type unsigned long is being implicitly cast to a long double.

3799
Maj_FLtoI
Implicit conversion: float to char.
An object of type float is being implicitly cast to a char.

3800
Maj_FLtoI
Implicit conversion: float to signed char.
An object of type float is being implicitly cast to a signed char.

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
31 of 181
A4 : 2003-02

3801
Maj_FLtoI
Implicit conversion: float to unsigned char.
An object of type float is being implicitly cast to an unsigned char.

3802
Maj_FLtoI
Implicit conversion: float to short.
An object of type float is being implicitly cast to a short.

3803
Maj_FLtoI
Implicit conversion: float to unsigned short.
An object of type float is being implicitly cast to an unsigned short.

3804
Maj_FLtoI
Implicit conversion: float to int.
An object of type float is being implicitly cast to a int.

3805
Maj_FLtoI
Implicit conversion: float to unsigned int.
An object of type float is being implicitly cast to an unsigned int.

3806
Maj_FLtoI
Implicit conversion: float to long.
An object of type float is being implicitly cast to a long.

3807
Maj_FLtoI
Implicit conversion: float to unsigned long.
An object of type float is being implicitly cast to an unsigned long.

3810
Maj_FLtoI
Implicit conversion: double to char.

An object of type double is being implicitly cast to a char.

3811
Maj_FLtoI
Implicit conversion: double to signed char.
An object of type double is being implicitly cast to a signed char.

3812
Maj_FLtoI
Implicit conversion: double to unsigned char.
An object of type double is being implicitly cast to an unsigned char.

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
32 of 181
A4 : 2003-02

3813
Maj_FLtoI
Implicit conversion: double to short.
An object of type double is being implicitly cast to a short.

3814
Maj_FLtoI
Implicit conversion: double to unsigned short.
An object of type double is being implicitly cast to an unsigned short.

3815
Maj_FLtoI
Implicit conversion: double to int.
An object of type double is being implicitly cast to a int.

3816
Maj_FLtoI
Implicit conversion: double to unsigned int.
An object of type double is being implicitly cast to an unsigned int.

3817
Maj_FLtoI
Implicit conversion: double to long.
An object of type double is being implicitly cast to a long.

3818
Maj_FLtoI
Implicit conversion: double to unsigned long.
An object of type double is being implicitly cast to an unsigned long.

3819
Maj_Small
Implicit conversion: double to float.

An object of type double is being implicitly cast to a float.

3821
Maj_FLtoI
Implicit conversion: long double to char.
An object of type long double is being implicitly cast to a char.

3822
Maj_FLtoI
Implicit conversion: long double to signed char.
An object of type long double is being implicitly cast to a signed char.

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
33 of 181
A4 : 2003-02

3823
Maj_FLtoI
Implicit conversion: long double to unsigned char.
An object of type long double is being implicitly cast to an unsigned char.

3824
Maj_FLtoI
Implicit conversion: long double to short.
An object of type long double is being implicitly cast to a short.

3825
Maj_FLtoI
Implicit conversion: long double to unsigned short.
An object of type long double is being implicitly cast to an unsigned short.

3826
Maj_FLtoI
Implicit conversion: long double to int.
An object of type long double is being implicitly cast to a int.

3827
Maj_FLtoI
Implicit conversion: long double to unsigned int.
An object of type long double is being implicitly cast to an unsigned int.

3828
Maj_FLtoI
Implicit conversion: long double to long.
An object of type long double is being implicitly cast to a long.

3829
Maj_FLtoI
Implicit conversion: long double to unsigned long.
An object of type long double is being implicitly cast to an unsigned long.


3830
Maj_Small
Implicit conversion: long double to float.
An object of type long double is being implicitly cast to a float.

3831
Maj_Small
Implicit conversion: long double to double.
An object of type long double is being implicitly cast to a double.

3832
Designed by
Maj_Pchar
Implicit conversion: char to long long.
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
34 of 181
A4 : 2003-02

An object of type char is being implicitly cast to a long long.
3833
Maj_Pchar
Implicit conversion: char to unsigned long long.

3834
Maj_UStoLS
Implicit conversion: unsigned char to long long.
An object of type unsigned char is being implicitly cast to a long long.

3837
Maj_StoUS
Implicit conversion: signed char to unsigned long long.
An object of type signed char is being implicitly cast to an unsigned long long.
positive values.
3839
Maj_StoUS
Implicit conversion: short to unsigned long long.
An object of type short is being implicitly cast to an unsigned long long.

positive values.
3840
Maj_UStoLS
Implicit conversion: unsigned short to long long.
An object of type unsigned short is being implicitly cast to a long long.

3843
Maj_StoUS
Implicit conversion: int to unsigned long long.
An object of type int is being implicitly cast to an unsigned long long.

positive values.
3844
Maj_UStoLS
Implicit conversion: unsigned int to long long.

An object of type unsigned int is being implicitly cast to a long long.

3847
Maj_StoUS
Implicit conversion: long to unsigned long long.

positive values.
3848
Maj_UStoLS
Implicit conversion: unsigned long to long long.
An object of type unsigned long is being implicitly cast to a long long.

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
35 of 181
A4 : 2003-02

3850
Maj_Pchar
Implicit conversion: long long to char.
An object of type long long is being implicitly cast to a char.

3851
Maj_Small
Implicit conversion: long long to signed char.
An object of type long long is being implicitly cast to a signed char.

3852
Maj_StoUS
Implicit conversion: long long to unsigned char.
An object of type long long is being implicitly cast to an unsigned char.

3853
Maj_Small
Implicit conversion: long long to short.
An object of type long long is being implicitly cast to a short.

3854
Maj_StoUS
Implicit conversion: long long to unsigned short.
An object of type long long is being implicitly cast to an unsigned short.

3855
Maj_Small
Implicit conversion: long long to int.
An object of type long long is being implicitly cast to an int.

3856
Maj_StoUS
Implicit conversion: long long to unsigned int.
An object of type long long is being implicitly cast to an unsigned int.

3857
Maj_Small
Implicit conversion: long long to long
An object of type long long is being implicitly cast to a long.

3858
Maj_StoUS
Implicit conversion: long long to unsigned long.

An object of type long long is being implicitly cast to an unsigned long.

3859
Maj_StoUS
Implicit conversion: long long to unsigned long long.
An object of type long long is being implicitly cast to an unsigned long long.
3860
Maj_ItoFL
Implicit conversion: long long to float.
An object of type long long is being implicitly cast to a float.

Implicit casts should be avoided
3861
Maj_ItoFL
Implicit conversion: long long to double.
An object of type long long is being implicitly cast to a double.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
36 of 181
A4 : 2003-02

3862
Maj_ItoFL
Implicit conversion: long long to long double.
An object of type long long is being implicitly cast to a long double.

3863
Maj_Pchar
Implicit conversion: unsigned long long to char.
An object of type unsigned long long is being implicitly cast to a char.

3864
Maj_UStoS
Implicit conversion: unsigned long long to signed char.
An object of type unsigned long long is being implicitly cast to a signed char.
3865
Maj_Small
Implicit conversion: unsigned long long to unsigned char.
An object of type unsigned long long is being implicitly cast to an unsigned char.
3866
Maj_UStoS
Implicit conversion: unsigned long long to short.
An object of type unsigned long long is being implicitly cast to a short.

3867
Maj_Small
Implicit conversion: unsigned long long to unsigned short.
An object of type unsigned long long is being implicitly cast to a unsigned short.
3868
Maj_UStoS
Implicit conversion: unsigned long long to int.
An object of type unsigned long long is being implicitly cast to an int.

3869
Maj_Small
Implicit conversion: unsigned long long to unsigned int.
An object of type unsigned long long is being implicitly cast to an unsigned int.
3870
Maj_UStoS
Implicit conversion: unsigned long long to long.

An object of type unsigned long long is being implicitly cast to a long.

3871
Maj_Small
Implicit conversion: unsigned long long to unsigned long.
An object of type unsigned long long is being implicitly cast to a unsigned long.
3872
Maj_UStoS
Implicit conversion: unsigned long long to long long.
An object of type unsigned long long is being implicitly cast to a long long.
Implicit casts should be avoided
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
37 of 181
A4 : 2003-02

3873
Maj_ItoFL
Implicit conversion: unsigned long long to float.
An object of type unsigned long long is being implicitly cast to a float.

3874
Maj_ItoFL
Implicit conversion: unsigned long long to double.
An object of type unsigned long long is being implicitly cast to a double.

3875
Maj_ItoFL
Implicit conversion: unsigned long long to long double.
An object of type unsigned long long is being implicitly cast to a long double.
3876
Maj_FLtoI
Implicit conversion: float to long long.
An object of type float is being implicitly cast to a long long.

3877
Maj_FLtoI
Implicit conversion: float to unsigned long long.
An object of type float is being implicitly cast to a unsigned long long.

3878
Maj_FLtoI
Implicit conversion: double to long long.
An object of type double is being implicitly cast to a long long.

3879
Maj_FLtoI
Implicit conversion: double to unsigned long long.
An object of type double is being implicitly cast to a unsigned long long.

3880
Maj_FLtoI
Implicit conversion: long double to long long.
An object of type long double is being implicitly cast to a long long.

3881
Maj_FLtoI
Implicit conversion: long double to unsigned long long.

An object of type long double is being implicitly cast to an unsigned long long.
3892
Min_Ops
Explicit cast is implicitly cast to another type.
For example:
int a;
int b;
a = (float)b;
*/
3900
/* b is explicitly cast to float, the result is then implicitly cast to int
Maj_Pchar
char value returned from signed char %s().
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
38 of 181
A4 : 2003-02

Implicit casts should be avoided. The result of a conversion to or from a plain 'char' datatype will depend on
whether the plain 'char' datatype is signed or unsigned. This is implementation defined behaviour and it is not
wise to make any assumptions. It is safer not to mix 'char' types in expressions.
3901
Maj_Pchar
char value returned from unsigned char %s().

3902
Maj_Pchar
'char' value returned from 'short %s()'.

3903
Maj_Pchar
char value returned from unsigned short %s().

wise to make any assumptions.
3904
Maj_Pchar
'char' value returned from 'int %s()'.

3905
Maj_Pchar
char value returned from unsigned int %s().

3906
Maj_Pchar
'char' value returned from 'long %s()'.

3907
Maj_Pchar
char value returned from unsigned long %s().


3908
Maj_Pchar
char value returned from float %s().

Implicit casts should be avoided. There may be a loss of precision here.
3909
Maj_Pchar
char value returned from double %s().

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
39 of 181
A4 : 2003-02

3910
Maj_Pchar
char value returned from long double %s().

3911
Maj_Pchar
unsigned char value returned from char %s().

3912
Maj_UStoS
unsigned char value returned from signed char %s().

Implicit casts should be avoided. An unsigned value is being converted to a signed type - the result may be
negative.
3913
Maj_UStoLS
unsigned char value returned from short %s().

3915
Maj_UStoLS
unsigned char value returned from int %s().

3917
Maj_UStoLS
unsigned char value returned from long %s().

3919
Maj_ItoFL
unsigned char value returned from float %s().

3920
Maj_ItoFL
unsigned char value returned from double %s().
An object of type unsigned char is being implicitly cast to a double.

3921
Maj_ItoFL
unsigned char value returned from long double %s().
An object of type unsigned char is being implicitly cast to a long double.

3922
Maj_Pchar
signed char value returned from char %s().

3923
Maj_StoUS
signed char value returned from unsigned char %s().
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
40 of 181
A4 : 2003-02

Implicit casts should be avoided. A signed datatype is being converted to an unsigned datatype and negative
values will be converted to large positive values.
3925
Maj_StoUS
signed char value returned from unsigned short %s().

3927
Maj_StoUS
signed char value returned from unsigned int %s().

3929
Maj_StoUS
signed char value returned from unsigned long %s().

3930
Maj_ItoFL
signed char value returned from float %s().

3931
Maj_ItoFL
signed char value returned from double %s().

3932
Maj_ItoFL
signed char value returned from long double %s().

3933
Maj_Pchar
short value returned from char %s().


information. The result of a conversion to or from a plain 'char' datatype will depend on whether the plain 'char'
datatype is signed or unsigned. This is implementation defined behaviour and it is not wise to make any
assumptions.
3934
Maj_Small
short value returned from signed char %s().
This is an implicit conversion to a smaller type - information may be lost.

When a value is converted to a smaller type and the result cannot be represented the result will depend on the
implementation.
3935
Maj_StoUS
short value returned from unsigned char %s().

When a value is converted to a smaller type the result depends on the implementation. e.g.
unsigned char
fn (
)
{
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
41 of 181
A4 : 2003-02

short x;
return x;
}
3936
Maj_StoUS
short value returned from unsigned short %s().
A value of type short is being returned from a function that is defined with type unsigned short.
The situation is illustrated below:
unsigned short foo ( void )
{
short ret;
/* ... */
return(ret);
}
A type conversion will be performed.
A signed type is being converted to an unsigned type and so negative values will be converted to large positive
values.
3938
Maj_StoUS
short value returned from unsigned int %s().
A value of type short is being returned from a function that is defined with type unsigned int.
unsigned int foo ( void )
{
short ret;
/* ... */
return(ret);
}

values.
3940
Maj_StoUS
short value returned from unsigned long %s().
A value of type short is being returned from a function that is defined with type unsigned long.
unsigned long foo ( void )
{
short ret;
/* ... */
return(ret);
}


values.
3941
Maj_ItoFL
short value returned from float %s().
A value of type short is being returned from a function that is defined with type float.
float foo ( void )
{
short ret;
/* ... */
return(ret);
}

There may be a loss of precision.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
42 of 181
A4 : 2003-02
3942
Maj_ItoFL
short value returned from double %s().
A value of type short is being returned from a function that is defined with type double.
double foo ( void )
{
short ret;
/* ... */
return(ret);
}

3943
Maj_ItoFL
short value returned from long double %s().
A value of type short is being returned from a function that is defined with type long double.
long double foo ( void )
{
short ret;
/* ... */
return(ret);
}

3944
Maj_Pchar
unsigned short value returned from char %s().
A value of type unsigned short is being returned from a function that is defined with type char.
char foo ( void )
{
unsigned short ret;
/* ... */
return(ret);
}

The conversion is taking place to a smaller datatype and may result in loss of information.
When an unsigned type is converted to a signed type, the result may be negative.
3945
Maj_UStoS
unsigned short value returned from signed char %s().

A value of type unsigned short is being returned from a function that is defined with type signed char.
signed char foo ( void )
{
unsigned short ret;
/* ... */
return(ret);
}

3946
Maj_Small
unsigned short value returned from unsigned char %s().
A value of type unsigned short is being returned from a function that is defined with type unsigned char.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
43 of 181
A4 : 2003-02

unsigned char foo ( void )
{
unsigned short ret;
/* ... */
return(ret);
}

3947
Maj_UStoS
unsigned short value returned from short %s().
A value of type unsigned short is being returned from a function that is defined with type short.
short foo ( void )
{
unsigned short ret;
/* ... */
return(ret);
}

3948
Maj_UStoLS
unsigned short value returned from int %s().

3950
Maj_UStoLS
unsigned short value returned from long %s().

3952
Maj_ItoFL
unsigned short value returned from float %s().
A value of type unsigned short is being returned from a function that is defined with type float.
float foo ( void )
{
unsigned short ret;
/* ... */
return(ret);
}


There may be a loss of precision
3953
Maj_ItoFL
unsigned short value returned from double %s().
A value of type unsigned short is being returned from a function that is defined with type double.
double foo ( void )
{
unsigned short ret;
/* ... */
return(ret);
}

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
44 of 181
A4 : 2003-02

3954
Maj_ItoFL
unsigned short value returned from long double %s().
A value of type unsigned short is being returned from a function that is defined with type long double.
{
unsigned short ret;
/* ... */
return(ret);
}
3955
Maj_Pchar
int value returned from char %s().
A value of type int is being returned from a function that is defined with type char.
char foo ( void )
{
int ret;
/* ... */
return(ret);
}

The result of a conversion to or from a plain 'char' type is dependent on whether plain 'char' is signed or not.
3956
Maj_Small
int value returned from signed char %s().
A value of type int is being returned from a function that is defined with type signed char.
{
int ret;
/* ... */
return(ret);
}

3957
Maj_StoUS
int value returned from unsigned char %s().
A value of type int is being returned from a function that is defined with type unsigned char.

{
int ret;
/* ... */
return(ret);
}

values.
3958
Maj_Small
int value returned from short %s().
A value of type int is being returned from a function that is defined with type short.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
45 of 181
A4 : 2003-02

short foo ( void )
{
int ret;
/* ... */
return(ret);
}

3959
Maj_StoUS
int value returned from unsigned short %s().
A value of type int is being returned from a function that is defined with type unsigned short.
{
int ret;
/* ... */
return(ret);
}

values.
3960
Maj_StoUS
int value returned from unsigned int %s().
A value of type int is being returned from a function that is defined with type unsigned int.
{
int ret;
/* ... */
return(ret);
}

values.
3962
Maj_StoUS
int value returned from unsigned long %s().
A value of type int is being returned from a function that is defined with type unsigned long.

{
int ret;
/* ... */
return(ret);
}

values.
3963
Maj_ItoFL
int value returned from float %s().
A value of type int is being returned from a function that is defined with type float.
float foo ( void )
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
46 of 181
A4 : 2003-02

{
int ret;
/* ... */
return(ret);
}

3964
Maj_ItoFL
int value returned from double %s().
A value of type int is being returned from a function that is defined with type double.
double foo ( void )
{
int ret;
/* ... */
return(ret);
}

3965
Maj_ItoFL
int value returned from long double %s().
A value of type int is being returned from a function that is defined with type long double.
{
int ret;
/* ... */
return(ret);
}

3966
Maj_Pchar
unsigned int value returned from char %s().
A value of type unsigned int is being returned from a function that is defined with type char.
char foo ( void )
{
unsigned int ret;
/* ... */
return(ret);
}

3967
Maj_UStoS
unsigned int value returned from signed char %s().
A value of type unsigned int is being returned from a function that is defined with type signed char.
{
unsigned int ret;
/* ... */
return(ret);
}
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
47 of 181
A4 : 2003-02

3968
Maj_Small
unsigned int value returned from unsigned char %s().
A value of type unsigned int is being returned from a function that is defined with type unsigned char.
{
unsigned int ret;
/* ... */
return(ret);
}

3969
Maj_UStoS
unsigned int value returned from short %s().
A value of type unsigned int is being returned from a function that is defined with type short.
short foo ( void )
{
unsigned int ret;
/* ... */
return(ret);
}

3970
Maj_Small
unsigned int value returned from unsigned short %s().
A value of type unsigned int is being returned from a function that is defined with type unsigned short.
{
unsigned int ret;
/* ... */
return(ret);
}


3971
Maj_UStoS
unsigned int value returned from int %s().
A value of type unsigned int is being returned from a function that is defined with type int.
int foo ( void )
{
unsigned int ret;
/* ... */
return(ret);
}

3972
Designed by
Maj_UStoLS
unsigned int value returned from long %s().
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
48 of 181
A4 : 2003-02

3974
Maj_ItoFL
unsigned int value returned from float %s().
A value of type unsigned int is being returned from a function that is defined with type float.
float foo ( void )
{
unsigned int ret;
/* ... */
return(ret);
}
3975
Maj_ItoFL
unsigned int value returned from double %s().
A value of type unsigned int is being returned from a function that is defined with type double.
double foo ( void )
{
unsigned int ret;
/* ... */
return(ret);
}

3976
Maj_ItoFL
unsigned int value returned from long double %s().
A value of type unsigned int is being returned from a function that is defined with type long double.
{
unsigned int ret;
/* ... */
return(ret);
}

3977
Maj_Pchar
long value returned from char %s().

A value of type long is being returned from a function that is defined with type char.
char foo ( void )
{
long ret;
/* ... */
return(ret);
}

3978
Designed by
Maj_Small
long value returned from signed char %s().
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
49 of 181
A4 : 2003-02

A value of type long is being returned from a function that is defined with type signed char.
{
long ret;
/* ... */
return(ret);
}

3979
Maj_StoUS
long value returned from unsigned char %s().
A value of type long is being returned from a function that is defined with type unsigned char.
{
long ret;
/* ... */
return(ret);
}

values.
3980
Maj_Small
long value returned from short %s().
A value of type long is being returned from a function that is defined with type short.
short foo ( void )
{
long ret;
/* ... */
return(ret);
}

3981
Maj_StoUS
long value returned from unsigned short %s().
A value of type long is being returned from a function that is defined with type unsigned short.

{
long ret;
/* ... */
return(ret);
}

values.
3982
Maj_Small
long value returned from int %s().
A value of type long is being returned from a function that is defined with type int.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
50 of 181
A4 : 2003-02

int foo ( void )
{
long ret;
/* ... */
return(ret);
}

3983 Maj_StoUS long value returned from unsigned int %s().
A value of type long is being returned from a function that is defined with type unsigned int.
{
long ret;
/* ... */
return(ret);
}

values.
3984
Maj_StoUS
long value returned from unsigned long %s().
A value of type long is being returned from a function that is defined with type unsigned long.
{
long ret;
/* ... */
return(ret);
}

values.
3985
Maj_ItoFL
long value returned from float %s().
A value of type long is being returned from a function that is defined with type float.

float foo ( void )

{
long ret;
/* ... */
return(ret);
}

3986
Maj_ItoFL
long value returned from double %s().
A value of type long is being returned from a function that is defined with type double.
double foo ( void )
{
long ret;
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
51 of 181
A4 : 2003-02

/* ... */
return(ret);
}

3987
Maj_ItoFL
long value returned from long double %s().
A value of type long is being returned from a function that is defined with type long double.
{
long ret;
/* ... */
return(ret);
}

3988
Maj_Pchar
unsigned long value returned from char %s().
A value of type unsigned long is being returned from a function that is defined with type char.
char foo ( void )
{
unsigned long ret;
/* ... */
return(ret);
}

3989
Maj_UStoS
unsigned long value returned from signed char %s().
A value of type unsigned long is being returned from a function that is defined with type signed char.
{
unsigned long ret;
/* ... */
return(ret);
}

3990
Maj_Small
unsigned long value returned from unsigned char %s().
A value of type unsigned long is being returned from a function that is defined with type unsigned char.
{
unsigned long ret;
/* ... */
return(ret);
}
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
52 of 181
A4 : 2003-02

3991
Maj_UStoS
unsigned long value returned from short %s().
A value of type unsigned long is being returned from a function that is defined with type short.
short foo ( void )
{
unsigned long ret;
/* ... */
return(ret);
}

3992
Maj_Small
unsigned long value returned from unsigned short %s().
A value of type unsigned long is being returned from a function that is defined with type unsigned short.
{
unsigned long ret;
/* ... */
return(ret);
}

3993
Maj_UStoS
unsigned long value returned from int %s().
A value of type unsigned long is being returned from a function that is defined with type int.
int foo ( void )
{
unsigned long ret;
/* ... */
return(ret);
}

3994
Maj_Small
unsigned long value returned from unsigned int %s().
A value of type unsigned long is being returned from a function that is defined with type unsigned int.
{
unsigned long ret;
/* ... */
return(ret);
}

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
53 of 181
A4 : 2003-02

3995
Maj_UStoS
unsigned long value returned from long %s().
A value of type unsigned long is being returned from a function that is defined with type long.
long foo ( void )
{
unsigned long ret;
/* ... */
return(ret);
}

3996
Maj_ItoFL
unsigned long value returned from float %s().
A value of type unsigned long is being returned from a function that is defined with type float.
float foo ( void )
{
unsigned long ret;
/* ... */
return(ret);
}

3997
Maj_ItoFL
unsigned long value returned from double %s().
A value of type unsigned long is being returned from a function that is defined with type double.
double foo ( void )
{
unsigned long ret;
/* ... */
return(ret);
}

3998
Maj_ItoFL
unsigned long value returned from long double %s().
A value of type unsigned long is being returned from a function that is defined with type long double.

{
unsigned long ret;
/* ... */
return(ret);
}

3999
Maj_FLtoI
float value returned from char %s().
A value of type float is being returned from a function that is defined with type char.
char foo ( void )
{
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
54 of 181
A4 : 2003-02

float ret;
/* ... */
return(ret);
}

4000
Maj_FLtoI
float value returned from signed char %s().
A value of type float is being returned from a function that is defined with type signed char.
{
float ret;
/* ... */
return(ret);
}

4001
Maj_FLtoI
float value returned from unsigned char %s().
A value of type float is being returned from a function that is defined with type unsigned char.
{
float ret;
/* ... */
return(ret);
}

4002
Maj_FLtoI
float value returned from short %s().
A value of type float is being returned from a function that is defined with type short.
short foo ( void )
{
float ret;
/* ... */
return(ret);
}


4003
Maj_FLtoI
float value returned from unsigned short %s().
A value of type float is being returned from a function that is defined with type unsigned short.
{
float ret;
/* ... */
return(ret);
}

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
55 of 181
A4 : 2003-02

4004
Maj_FLtoI
float value returned from int %s().
A value of type float is being returned from a function that is defined with type int.
int foo ( void )
{
float ret;
/* ... */
return(ret);
}

4005
Maj_FLtoI
float value returned from unsigned int %s().
A value of type float is being returned from a function that is defined with type unsigned int.
{
float ret;
/* ... */
return(ret);
}

4006
Maj_FLtoI
float value returned from long %s().
A value of type float is being returned from a function that is defined with type long.
long foo ( void )
{
float ret;
/* ... */
return(ret);
}

4007
Maj_FLtoI
float value returned from unsigned long %s().
A value of type float is being returned from a function that is defined with type unsigned long.

{
float ret;
/* ... */
return(ret);
}

4010
Maj_FLtoI
double value returned from char %s().
A value of type double is being returned from a function that is defined with type char.
char foo ( void )
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
56 of 181
A4 : 2003-02

{
double ret;
/* ... */
return(ret);
}

4011
Maj_FLtoI
double value returned from signed char %s().
A value of type double is being returned from a function that is defined with type signed char.
{
double ret;
/* ... */
return(ret);
}

4012
Maj_FLtoI
double value returned from unsigned char %s().
A value of type double is being returned from a function that is defined with type unsigned char.
{
double ret;
/* ... */
return(ret);
}

4013
Maj_FLtoI
double value returned from short %s().
A value of type double is being returned from a function that is defined with type short.
short foo ( void )
{
double ret;
/* ... */
return(ret);
}

4014
Maj_FLtoI
double value returned from unsigned short %s().
A value of type double is being returned from a function that is defined with type unsigned short.
{
double ret;
/* ... */
return(ret);
}

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
57 of 181
A4 : 2003-02
4015
Maj_FLtoI
double value returned from int %s().
A value of type double is being returned from a function that is defined with type int.
int foo ( void )
{
double ret;
/* ... */
return(ret);
}

4016
Maj_FLtoI
double value returned from unsigned int %s().
A value of type double is being returned from a function that is defined with type unsigned int.
{
double ret;
/* ... */
return(ret);
}

4017
Maj_FLtoI
double value returned from long %s().
A value of type double is being returned from a function that is defined with type long.
long foo ( void )
{
double ret;
/* ... */
return(ret);
}
4018
Maj_FLtoI
double value returned from unsigned long %s().
A value of type double is being returned from a function that is defined with type unsigned long.

{
double ret;
/* ... */
return(ret);
}

4019
Maj_Small
double value returned from float %s().
A value of type double is being returned from a function that is defined with type float.
float foo ( void )
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
58 of 181
A4 : 2003-02

{
double ret;
/* ... */
return(ret);
}

4021
Maj_FLtoI
long double value returned from char %s().
A value of type long double is being returned from a function that is defined with type char.
char foo ( void )
{
long double ret;
/* ... */
return(ret);
}

4022
Maj_FLtoI
long double value returned from signed char %s().
A value of type long double is being returned from a function that is defined with type signed char.
{
long double ret;
/* ... */
return(ret);
}
4023
Maj_FLtoI
long double value returned from unsigned char %s().

A value of type long double is being returned from a function that is defined with type unsigned char.
{
long double ret;
/* ... */
return(ret);
}
4024
Maj_FLtoI
long double value returned from short %s().
A value of type long double is being returned from a function that is defined with type short.
short foo ( void )
{
long double ret;
/* ... */
return(ret);
}
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
59 of 181
A4 : 2003-02

4025
Maj_FLtoI
long double value returned from unsigned short %s().
A value of type long double is being returned from a function that is defined with type unsigned short.
{
long double ret;
/* ... */
return(ret);
}

4026
Maj_FLtoI
long double value returned from int %s().
A value of type long double is being returned from a function that is defined with type int.
int foo ( void )
{
long double ret;
/* ... */
return(ret);
}

4027
Maj_FLtoI
long double value returned from unsigned int %s().
A value of type long double is being returned from a function that is defined with type unsigned int.
{
long double ret;
/* ... */
return(ret);
}
4028
Maj_FLtoI
long double value returned from long %s().

A value of type long double is being returned from a function that is defined with type long.
long foo ( void )
{
long double ret;
/* ... */
return(ret);
}

4029
Maj_FLtoI
long double value returned from unsigned long %s().
A value of type long double is being returned from a function that is defined with type unsigned long.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
60 of 181
A4 : 2003-02

{
long double ret;
/* ... */
return(ret);
}

4030
Maj_Small
long double value returned from float %s().
A value of type long double is being returned from a function that is defined with type float.
float foo ( void )
{
long double ret;
/* ... */
return(ret);
}

4031
Maj_Small
long double value returned from double %s().
A value of type long double is being returned from a function that is defined with type double.
double foo ( void )
{
long double ret;
/* ... */
return(ret);
}

4032
Maj_Pchar
char value returned from long long %s().

4033
Maj_Pchar
char value returned from unsigned long long %s().

An object of type char is being implicitly cast to an unsigned long long.

4034
Maj_UStoLS
unsigned char value returned from long long %s().

4037
Maj_StoUS
signed char value returned from unsigned long long %s().

4039
Designed by
Maj_StoUS
short value returned from unsigned long long %s().
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
61 of 181
A4 : 2003-02

4040
Maj_UStoLS
unsigned short value returned from long long %s().

4043
Maj_StoUS
int value returned from unsigned long long %s().

QAC-Rule 4044
4044
Maj_UStoLS
unsigned int value returned from long long %s().

4047
Maj_StoUS
long value returned from unsigned long long %s().
An object of type long is being implicitly cast to an unsigned long long.

4048
Maj_UStoLS
unsigned long value returned from long long %s().

4050
Maj_Pchar
long long value returned from char %s().

4051
Maj_Small
long long value returned from signed char %s().

4052
Maj_StoUS
long long value returned from unsigned char %s().


4053
Maj_Small
long long value returned from short %s().

4054
Maj_StoUS
long long value returned from unsigned short %s().

4055
Maj_Small
long long value returned from int %s().
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
62 of 181
A4 : 2003-02

4056
Maj_StoUS
long long value returned from unsigned int %s().

4057
Maj_Small
long long value returned from long %s().

4058
Maj_StoUS
long long value returned from unsigned long %s().

4059
Maj_StoUS
long long value returned from unsigned long long %s().
4060
Maj_ItoFL
long long value returned from float %s().

4061
Maj_ItoFL
long long value returned from double %s().

4062
Maj_ItoFL
long long value returned from long double %s().

4063
Maj_Pchar
unsigned long long value returned from char %s().

4064
Maj_UStoS
unsigned long long value returned from signed char %s().

4065
Maj_Small
unsigned long long value returned from unsigned char %s().
4066
Maj_UStoS
unsigned long long value returned from short %s().

4067
Designed by
Maj_Small
unsigned long long value returned from unsigned short %s().
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
63 of 181
A4 : 2003-02

An object of type unsigned long long is being implicitly cast to an unsigned short.
4068
Maj_UStoS
unsigned long long value returned from int %s().

4069
Maj_Small
unsigned long long value returned from unsigned int %s().
4070
Maj_UStoS
unsigned long long value returned from long %s().

4071
Maj_Small
unsigned long long value returned from unsigned long %s().
An object of type unsigned long long is being implicitly cast to an unsigned long.
4072
Maj_UStoS
unsigned long long value returned from long long %s().
4074
Maj_ItoFL
unsigned long long value returned from double %s().

4075
Maj_ItoFL
unsigned long long value returned from long double %s().
4076
Maj_FLtoI
float value returned from long long %s().

4077
Maj_FLtoI
float value returned from unsigned long long %s().

An object of type float is being implicitly cast to an unsigned long long.

4078
Maj_FLtoI
double value returned from long long %s().

4079
Maj_FLtoI
double value returned from unsigned long long %s().
An object of type double is being implicitly cast to an unsigned long long.

4080
Designed by
Maj_FLtoI
long double value returned from long long %s().
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
64 of 181
A4 : 2003-02

4081
Maj_FLtoI
long double value returned from unsigned long long %s().

Make sure the pointers to be used are valid.
Justification
A common source of error is the use of deallocated pointers, de-referencing null pointers, and improper pointer
alignment after casting pointers to a different type.
Note: Because the behaviour of corrupt pointers is different on an emulator and flash system, these bugs are
extremely hard to track and the concequences of a pointer bug typically are fatal - corrupted memory (pointing to
RAM) or loss of data (pointing to ROM).
Example
...
int8* EEPX_pi8DataBuffer = malloc();
...
if(...)
...
free EEPX_pi8DataBuffer;
....
/* make sure the pointer is still valid !!! */
if (EEPX_piDataB8uffer != NULL)
{
EEPX_sData2String(EEPX_pi8DataBuffer);
...
QAC-Rules: 0306, 0307, 0308, 0309, 0310, 0311, 0312, 0313, 0431, 0432, 0488, 0489, 0562, 0563, 0673, 0757,
3003, 3216, 3217, 4140
0306
ISO_ImplDef
[I] Cast between pointer and integral type is implementation defined.

It is dangerous to cast to and from integers as the implementation defines the size of the integer required and the
result of the cast. This could result in a loss of information. The exception is the casting of integer value zero
which will produce a NULL pointer.
0307
ISO_ImpU
[u] This cast is not defined for pointers.
The ISO standard only defines certain casts involving pointers. Others, like the casting of a pointer to a float, are
undefined and therefore not portable.
There are two situations under which casting between pointers of different types is safe. Those are:
(1) Casting of a pointer to another pointer with the same or less strict alignment and back again.
(2) Casting of a pointer to a function of one type to a pointer to a function of another type (and back again)
provided that no attempt is made to execute the function between casts (as the function return type would
obviously disagree with the intermediate pointer type and therefore lead to undefined behaviour).
0308
Designed by
Min_Ops
Non-portable cast involving pointer to an incomplete type.
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
65 of 181
A4 : 2003-02

ISO says that any cast from a complete to an incomplete type is undefined. Check that the target object has been
defined completely. Perhaps you are missing an include file or you have misspelt the object name. e.g.
struct x;
int i;
struct x * ptr;
p = (struct x*)&i;
attempts to take the address of 'i' and convert it to an address of an incomplete type.
incomplete type - any type which describes an object for which information required to determine its size is
missing.
0309
ISO_ExpU
[U] Integral type is not large enough to hold a pointer value.
The receiving integral type is not large enough to hold the value of the pointer being cast to it. This means that
during the casting it is very likely that information will be lost - the value of the integral type will no longer
represent the location held by the pointer.
There are two situations under which casting between pointers is safe. Those are:
0310
Min_Ops
Casting to different object pointer type.
You are casting a pointer to another pointer type. This is often disallowed in programming standards, by reason of
safety, portability, and readability.
For example:
void function(char *string, int *number)
{
int * pi;
char * pc;
pc = (char *)number;
pi = (int *)string;
/* Message 310 */
/* Message 310 & 3305 */
0311
Maj_Ops
Dangerous pointer cast results in loss of const qualification.

According to the ISO standard (6.3.16.1), a pointer can only be assigned to another pointer if "both operands are
pointers to qualified or unqualified versions of compatible types, and the type pointed to by the left has all of the
qualifiers of the type pointed to by the right". An assignment statement which violates this rule will generate the
constraint error message 562. On the other hand, if the right hand operand is the subject of an appropriate cast,
such an assignment is allowed. Such casts must be considered dangerous and a warning message is generated.
Message 311 indicates that const qualification has been lost from the object pointed to. Message 312 indicates
that volatile qualification has been lost from the object pointed to.
For example:
int
*pi;
const
int
*pci;
...
pi = pci;
pi = (int *)pci;
Designed by
/* Ptr. to int
/* Ptr to con. int
*/
*/
/* Message 562 - Constraint Error */

/* Message 311 */
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
66 of 181
A4 : 2003-02
0312
Maj_Ops
Dangerous pointer cast results in loss of volatile qualification.
that volatile qualification has been lost from the object pointed to.
For example:
int
*pi;
volatile int
*pvi;
...
pi = pvi;
pi = (int *)pvi;
...
0313
Min_Ops
/* Ptr. to int
/* Ptr to volatile int
*/
*/

/* Message 312 */
Casting to different function pointer type.
You are casting a pointer to a function of one type to a pointer to a function of a different type. This is permitted in
the C language under certain conditions, but is often disallowed in programming standards, for reasons of safety,
portability, and readability.
For example:
extern void error( S8 * x );
...
void (* pf)( S32 * );
...
pf = (void (*)( S32 *)) error;
...
0431
Constraint
/* Message 0313 */
[C] Pointer argument has differently qualified base type.
Pointer is converted and may be invalid. The behaviour is undefined.

0432
Constraint
[C] Argument should be compatible pointer type.
Cast on a pointer type to a type which is not compatible is implementation-defined. The behaviour is undefined.
0488
Min_Ops
Performing pointer arithmetic.

Pointer arithmetic is often disallowed in programming standards because it is a potential source of problems. This
message will be generated whenever an expression involves pointer arithmetic. One exception allowed under this
rule is to increment or decrement a pointer; this operation is trapped by message 489.
For example:
int
*px;
/* ... */
px = px + 2;
/* Message 488 */
++px;
/* OK */
0489
Min_Ops
Arithmetic operations shall not be performed on pointers - even with the value
"1"..
This message, 489, will be used in conjunction with message 488. Message 488 is generated whenever a pointer
is the subject of an arithmetic operation. However increment and decrement operations are specifically excluded
from message 488 and are trapped by 489.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
67 of 181
A4 : 2003-02

For example:
int
*px;
/* ... */
px = px + 2;
/* Message 488 */
px = px - 1;
/* Message 489 */
++px;
/* Message 489 */
0562
Constraint
[C] Right operand of assignment is a pointer to a differently qualified base type.
The ISO standard requires that in a simple assignment when both operands are pointers to qualified or
unqualified versions of compatible types, the type pointed to by the left has all the qualifiers of the type pointed to
by the right. For example:
static void f(void)
{
char*
cp;
const char* ccp;
cp=ccp;
}
0563
Constraint
[C] Right operand of assignment does not have a compatible pointer type.
The C language does not permit implicit conversion of pointers. A pointer object can only be initialised or
assigned a value which is a pointer to a compatible type. For example:
static void fn(void)
{
const int* const ip = 0;
char*
cp;
cp = ip;
/* Message 0563 */
}
0673
Constraint
[C] Pointer initializer has a differently qualified base type.
You have attempted to initialize an object of pointer type with a pointer type object of differing qualification.
Typically qualification refers to const qualification. For example:
static void fn(void)
{
const char* gcp;
char*
gp = gcp; /* Differently qualified base pointer */
}

0757
Constraint
[C] 'return' expression is a pointer to a differently qualified type than the function
return type.
On execution of a return statement, the value of the expression returned is the value of the expression part of the
return statement. If the expression has a type different from that of the function in which it appears, it is converted
as if it were *assigned* to an object of that type. In the example below the function return type is int*, but the type
of the expression provided to the return statement is 'signed volatile int*'.
int* fn(signed volatile int* p1)
{
return p1; /* return type mismatch */
}
3003
Designed by
Maj_Ops
This token is a suspicious NULL pointer constant.
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
68 of 181
A4 : 2003-02

Programmers often get confused between a null pointer and a pointer to an empty character string, which is a
pointer to a null character ('\0'). This message is generated when a pointer is assigned to a null character. Such
an operation would involve an implicit cast and is likely to be a mistake. For example:
#include
char *p = '\0';
/* Message 3003 */
char *q = (voidf *) 0; /* OK */
char *r = NULL; /* OK */
3216
Maj_Ops
Address of object being assigned has more restricted scope than object being
assigned to.
Once the object that was assigned goes out of scope, the contents of the object that was assigned to no longer
points to valid data. For example:
int main()
{
int *a;
{
int b;
a = &b;
}
/* value in 'a' is pointing to data out of scope! */
}
3217
Maj_Ops
The address of a local variable is being assigned to a static variable which

persists when the memory for the local variable is freed.
Assigning the address of a local variable to a static variable is dangerous, since once the local variable goes out
of scope, the address the static variable points to is invalid. For example:
void f(void)
{
static int* v;
int a;
v = &a; /* Can I always access 'a' through '*v' ? */
/* NO! The address of 'a' could change across function calls */
}
4140
Maj_Ops
Function returns address of local data.
A non-static variable defined locally in a function will cease to exist after a return from the function. It is therefore
meaningless, if not dangerous, to return the address of such a variable. Perhaps the variable needs to be
declared static. For example:

int *func ( int x )

{
int a=0;
/* ... */
return &a;
}
/* Message 4140 */

The address of an object must not be stored in an object with larger scope, than the object whose address is
being stored.
If different lifetime is needed, there must exist a syncronisation mechanism, that invalidates the large scope
pointer (e.g. assign NULL) when the object is deleted.
Justification
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
69 of 181
A4 : 2003-02

Different scopes may lead to pointers that reference deallocated memory, which cause run time errors when
used. A typical example is the return of a local address:
Example
/* DLIB__pbDataStart : global pointer
* pbRxParmBuffer
: pointer to local data
*/
DLIB__pbDataStart=pbRxParmBuffer+3;
/* remember data pointer */
The above example will only work if the data pbRxParmBuffer points at are not freed on function exit . Otherwise
DLIB__pbDataStart will point to memory that is being reused by other functions - the validity of the data is pure
chance.
Other example: function returning local address:
char* my_func(void){
char* ret_val = "STR_INITIALIZER";
...
return ret_val;
}
/* ret_val goes out of scope. Its existence on the stack is pure chance.
* In short test examples this often works, in systems under stress this WILL go
* wrong!
*/
int f()
{
char * myString = my_func();
}
/* myString will point to deallocated memory! */
Note that ANSI C does not require const data to be located at read-only sections. So you can not use const to
solve the deallocation problem. The following variation works with more compilers than the previous example
(even under stress), but still is not portable.
char* const my_func(void) /* returns pointer to constant string */
{
char* const ret_val = "STR_INITIALIZER";
return ret_val;
}
/* ret_val goes out of scope. What it points to is const and therefore still exists */
int f()
{
char * const myString = my_func();
/*
/*
myString MAY point to deallocated */

memory!
*/

QAC-Rules: 3216, 3217, 3225, 3348, 3349, 4140

3216
Maj_Ops
assigned to.
int main()
{
int *a;
{
int b;
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
70 of 181
A4 : 2003-02

a = &b;
}
}
3217
Maj_Ops

void f(void)
{
static int* v;
int a;
}
3225
Maj_Ops
Function parameter returns address of a local non-static object.
void foo(int **appi)
{
int bi = 1;
...
*appi = &bi;
/* 3225 */
...
return;
}
3348
Maj_Stmt
This function argument points to uninitialised data, but the receiving parameter
is declared as a pointer to const.
It may be appropriate to pass a pointer to some uninitialised data as an argument to a function that will then
initialise the data. However, it can never be appropriate to pass such a pointer to a function if the corresponding
parameter is declared as "pointer to const", because no initialisation is possible. For example:
extern int foo2(const int *p);

int foo1(void)
{
int y;
int r;
r = foo2(&y);
...
3349
/* Message 3348 */
Maj_Stmt
This function argument may point to uninitialised data, but the receiving
parameter is declared as a pointer to const.
This message will be generated if there is some possibility that the function argument points to uninitialised data.
It may be appropriate to pass a pointer to some uninitialised data as an argument to a function that will then
initialise the data. However, it can never be appropriate to pass such a pointer to a function if the corresponding
parameter is declared as "pointer to const", because no initialisation is possible. For example:
extern int foo2(const int *p);
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
71 of 181
A4 : 2003-02

int foo1(int a)
{
int x;
int r;
if (a == 1)
{
x = 1;
}
r = foo2(&x);
...
3140
/* Message 3349 */
Min_Stmt
Null statement occurs on a line by itself without comment.
An empty statement occuring on its own without comment can be considered dangerous. Is this what was
intended?
For example:
static void foo( void )
{
int n=0;
;
/* does not generate here */
/* Message 3140 will be generated on the following line */
;
n++;
}

If a macro body contains any operator, enclose the body within parentheses. Always enclose any instances of
macro parameters within parentheses.
Justification
Omitting parentheses around macro bodies and parameters can lead to unexpected interpretation of the
expanded code (as in the AWFUL example given below).
Example
/*These
#define
#define
#define
are alright: */
OK 0
GOOD (-1)
SQUARE(a) ((a) * (a))
/* But not like these: */

#define BAD -1
#define AWFUL(a,b) a * b
x = AWFUL(1 + 1, 1) * 4;
x = 1 + 1 * 1 * 4;
/* looks like 8... */

/* ... but is 5 instead */
Note:
If the macro definition is a simple constant definition - even one with a cast operator - the brackets need not to be
there.
QAC-Rules: 3409, 3410, 3411, 3430
3409
Min_Prepro
Macro body not enclosed in ().
This message is only generated if the macro body contains operators and is not enclosed in ( ). If these operators
and the operands on which they operate are not enclosed within parentheses then use of the macro in certain
contexts could give rise to unexpected results. Parenthesising macro bodies prevents unexpected precedence
problems and improves reliability.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
72 of 181
A4 : 2003-02

For example:
#define ADD(a,b) a + b
/* ... */
x = 2 * ADD( 1, 2 );
/* ... */.
This statement expands to "x = 2 * 1 + 2" which gives rise to confusion over the intended precedence. The macro
definition would have been better written as:
#define ADD(a,b) ((a) + (b))
3410
Min_Prepro
Macro parameter not enclosed in ().
This message is specific to function-like macros and suggests that the macro parameters should be enclosed
within parentheses.
#define SQUARE(a) (a * a)
should read
#define SQUARE(a) ((a) * (a))
Enclosing the parameters within parentheses avoids the associated problems that can be produced when the
macro arguments are expressions themselves.
...
x = SQUARE(1 + 1)
The code fragment above assigns the value (1 + (1*1) + 1)=3 to 'x' instead of the perhaps expected ((1+1) *
(1+1))=4.
Parenthesising the parameters in the body of a macro definition avoids problems associated with operator
precedence.
3411
Min_Prepro
Macro defined with unbalanced brackets or parentheses.
Although it is legal to define macros with unbalanced brackets '[]' or parentheses '()' it is more likely that such
occurrences will represent bugs. e.g.
#define OPEN_BRACKET [
...
You should avoid creating macros with unbalanced brackets or parentheses unless you have a very good reason
for doing so.
In such cases you should always ensure that the code is adequately commented to reflect your intentions.
3430
Min_Prepro
Macro argument expression requires parentheses.
If the argument to a macro is an expression it should be parenthesised.

#define MULTIPLY(x,y) ( x * y ) /* better if written #define MULTIPLY(x,y) ( ( x ) * ( y ) )

*/
...
int a=3;
int b=5;
x = MULTIPLY(a+b,a+b);
/* Message 3430 */
This evaluates to ( 3+5*3+5 ) = (3+(5*3)+5) = 23, whereas the required result was probably 64.

Use the typedefs in cdef.h instead of using the built-in types.
Exception: Pointers and arrays do not need a type declaration, but a type declaration is permitted for complex
data types.
Justification
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
73 of 181
A4 : 2003-02

First, the standard C types int, char, short und long have implicit attributes (sign, size) that are implementation
defined. Basic types from cdef.h are fully qualified, leading to better portability.
Second, bitfield implementation is compiler specific. Accessing bitfield memory with a non-bitfield variable (e.g.
16 bits via 2 bytes) requrires detailed knowledge about the compiler behaviour regarding byte sequence
(endianess), bit sequence and bit stuffing. This knowledge is provided by the various versions of cdef.h. Each
defines union types bit8 and bit16 that allow to access bitfields via byte or short.
The following table lists the basic types in cdef.h (Note: the types marked with old should not
be used for new implementations, but are accepted in old implementations. It is recommended
however, to change the definitions to new types when maintenance activities take place):
Basic type
Description
Example
uint8 (old: byte)
unsigned 8 bit value
uint8
EEPX_u8Example;
uint8 * EEPX_pu8Example;
uint8
EEPX__au8Buf0[ 10 ];
uint16 (old: word)
uint16
EEPX_u16Example;
uint16 * EEPX_pu16Data;
uint32 (old: dword)
uint32 EEPX_u32Example;
int8
signed 8 bit value
int8
EEPX_i8Example;
uint8 * EEPX_pi8Example;
int16
signed 16 bit value
int16 EEPX_i16Example;
int32
signed 32 bit value
int32 EEPX_i32Example;
bool
boolean value: True,False
bool EEPX_boExample;
void
dummy value
void EEPX_vExample;
bit variable (union) with 8 bits
bit8 EEPX_bi8Example;
EEPX_bi8Example.F._0 = 1;
EEPX_bi8Example.B = 0xFF;
bit8
Supporting Bit Access and 8Bit

Flag Access

bit16
Supporting Bit Access and 2*8,

16Bit Flag Access
bit32
Supporting Bit Access and 4*8,

2*16 and 32Bit Flag Access
EEPX_bi16Example.B._0 = 0xFF;
EEPX_bi16Example.W = 0xFFFF;
EEPX_bi32Example.B._0 = 0xFF;
EEPX_bi32Example.W._0 = 0xFFFF;
EEPX_bi32Example.DW=0xFFFFFFFF;
Example
This example shows 2 type definitions based directly and indirectly on cdef.h.
/* A1c1.h: */
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
74 of 181
A4 : 2003-02

#include "cdef.h"
typedef uint8 A_tu8ExampleType;
"uint8" */
/* direct reference to cdef type
/* B1c1.h: */
#include "A1c1.h"
typedef A_tu8ExampleType B_tu8AnotherExampleType;
"uint8" */
/* indirect reference to cdef type
Note
Because int is the "natural" data format, it may decrease performance to give high frequently used
variables another type. Note that optimizations like this are always platform specific and might decrease
portability.
Note that float and double should not be used, because FPUs are not available. Float types are
implementation defined and require cdef support ( e.g. float24 for 6byte floats)
QAC-Rules: -3.1.14 Rule r2-56 | Mandatory
C++ keywords must behave the same in C and C++ context.
Here is a complete list of C++ keqwords:
and
catch
explicit
namespace
or_eq
template
typename
and_eq
class
export
new
private
this
using
asm
compl
false
not
protected
throw
virtual
bitand
const_cast
friend
net_eq
public
true
wchar_t
bitor
delete
inline
operator
reinterpret_cast
try
xor
bool
dynamic_cast
mutable
or
static_cast
typeid
xor_eq
Some of these C++ keywords are defined in C standard headers as macros:

and
and_eq bitand
bitor
compl
not
not_eq
or
or_eq
wchar_t
xor
xor_eq
Treat them like keywords; do not #undef or test them with #if defined(...)
If you define a C++ keyword as a C identifier or macro, wrap definition with test for __cplusplus, which has to
be set by every ANSI compliant C++ compiler. Check that your C definition behaves like the C++ keyword.
/* cdef.h */

#ifndef __cplusplus
compilation */
typedef unsigned char
*/
#endif
/* use Std ANSI C++ macro to detect C++

bool;
/* Boolean datatype
(keyword in C++)
Justification
Ignoring this rule will obviously lead to totally different interpretation of the code in a C and C++ environment. In
some cases this will produce syntax errors, which can fairly easyly be fixed, however, there are cases in which
legal constructs evolve, leading to semantic errors, that are very hard to find.
Using non standard meanings of C++ keywords increases confusion.
Example
This example uses a function "new" which will cause an error when read by a C++ compiler:
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
75 of 181
A4 : 2003-02

int var = new(something); /* "new" is an operator in C++ that does not return int
*/
QAC-Rules: 1300, 1301

1300
Min_Cpp
'%s' is a keyword in C++.
The specified identifier is a recognised C++ keyword. This will normally result in a syntax violation when trying to
compile using a C++ compiler.
...
int class;
...
'class' is a C++ keyword - avoid using names which duplicate C++ keywords.
1301
Min_Cpp
'%s' is a keyword in some C++ implementations.
This keyword is an anachronism in C++ but is still supported by many compilers. e.g
.
int overload; /* warning 1301 - may be a keyword: */
3.1.15 Rule r4.11 | Recommended

Identifiers must not be made up of special characters.
The following chars are allowed:
A-Z
a-z
0-9
_ (underline)
Avoid leading underscores, since it might confuse the linker.
Justification
Compilers interpret special characters differently. Most compilers do not acccept them in identifiers.
Example
None


Identifiers must comply with VDO naming conventions.
They should be
as long as necessary,
as short as possible,
as self-explanatory as possible.
Identifiers comprise the following elements:
Module prefix
(0 or 3 to 5
characters)
Scope
(0 to 2 characters)
Type identifier
Name
(1 to 7 characters)
Suffix
(optional)
Example
Designed by
EEP_u8Data is not very well selected, what data?

LMP_u8LampStatus is better, but still not very good. How to interpret LMP_u8LampStatus ==
TRUE, on or off? A better solution could be LMP_u8LampIsOn == TRUE.
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
76 of 181
A4 : 2003-02
MOV_u8EngineViaSatteliteBusTriggerHighPulseStatus and
MOV_u8EngineViaSatteliteBusTriggerLowPulseStatus are too long and the difference is only
visible in the middle of the name. OK for a automated parser, but not for a human reader.
Module Prefix
The module prefix states the source and also the place of definition of an identifier.
Formation rules:
Module name (without version label!)
3 to 5 characters
All characters are written in UPPER CASE.
There is no module prefix for function-local and system-relevant (global macros, global definitions) identifiers. The
module prefix may not be used for individual elements of unions or structures, as it is already given in the name
of the union/structure. Enumerated constants (for non-module-local lists) must use the module-prefix as they are
treated like normal constants. Compilers do no type-checking on them!
Note: A system-relevant identifier has the same scope like a system wide identifier. He does not belong to a
specific module but is defined in system files like cdef.h, sysconst.h etc.
Scope
Scope defines the valid area of an identifier, i.e. where it is "visible".
Definition: "system-wide"
A system-wide identifier has a meaning throughout the system and can be imported by other modules.
Declaration is done in the C1.H file.
Definition: "module-global"
A module-global variable has a meaning only within the module (a module may comprise more than one sourcefile). When the module comprises only one file, "module-global" is identical to "file-local". Module global variables
are declared in the Cx.C files, access from other internal module files is done via extern.
Definition: "file-local"
A file-local identifier has a meaning only within its own file. File local variables should be declared as static inside
the Cx.C file using the variable. File-local identifiers are often used only for debugging purposes.
Definition: "function-local"
A function-local identifier has a meaning only within its own function. Function local variables are declared inside
the function using the variable.
Formation rules:
0 underscore: function local, no module prefix
(e.g. u8Byte)
1 underscore: system-wide
(e.g. EEPX_u8Byte)
2 underscores: module-global or file-local
(e.g. EEPX__u8Byte)
Identifiers that begin with an underscore are not allowed (they are reserved for the compiler). Therefore the scope
underline characters are only inserted for identifiers with a module-prefix.

Type Identifier
The type gives information on the usage type of the identifier. This needs to be carefully selected for complex
types.
System-relevant identifiers require no type identifier.
Allocation identifier (0 or 1 character)
Data type identifier (1 to 6 characters)
Allocation identifier:
Allocation
identifier
Defined in C with... Meaning
Example
#define
#define EEPX_nExample 5
Designed by
Numeric constant, that is created
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
77 of 181
A4 : 2003-02

for direct addressing in program
code, not in a data segment.
#define nu8Example (uint8) 3
Typedef
Type definition
typedef uint8 EEPX_tu8Example;
Const
Rom constants
const uint8 EEPX_ru8Example
All other allocation areas (variables

etc.)
uint8 EEPX_u8Example;
None
Type identifiers have to be used for function return-values. Function-like macros are treated as functions.
Data type identifier:
The data type identifier consists of 0 or 1 pointer identifier and 1 basic type identifier.
pointer
identifier

basic type
identifier
Designed by
'p'
pointer to ...
'a'
Array of ...
'pa'
Pointer to array of ...
'ap'
Array of pointers to ...
'c'
char
's'
char[], Null terminated string
'b'
byte - should not be used for new implementation, use

uint8 instead
'w'
word - should not be used for new implementation, use

uint16 instead
'dw'
dword - should not be used for new implementation, use

uint32 instead
'u8'
uint8, successor of byte
'u16'
unit16, successor of word
'u32'
uint32, successor of dword
'i8'
int8
'i16'
int16
'i32'
int32
'f'
float
'd'
double
'bo'
bool
'v'
void
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
78 of 181
A4 : 2003-02

'un'
union
'st'
structure
'en'
enum
'bi8'
bit8
'bi16'
bit16
'bi32'
bit32
'bi'
Bit variable
'x'
More complex data types (if no standard notation

available)
Name
The name identifies the functional use, or semantics of the identifier. It should be in English !
Formation rules:
Always begin with a capital letter.
Concatenated names are denoted by capitalising each sub-word.
Digits are allowed.
Underscores are allowed.
Function names should be identified by a verb and an object-name, e.g. GetStatus
Identifiers should be clearly distinguishable and not only differ in case (e.g. should 'NotValid' be
defined, 'Notvalid' is no longer permitted).
Suffix
A suffix is an optional extension of the identifier's description:
Formation rules:
Always begins with an underscore.
Second character is upper case.
The rest of the characters are lower case.
The following suffixes are defined:

Meaning
_Alm
Alarm
_Cfg
Configuration constant etc

Suffix
_Con
Confirmation e.g. Function called after end of a command.
_Csr
Driver Cancel Service Routine
_Ctr
Counter
_Dbg
Debug support
_Flg
Flag
_Ind
Indication Routine e.g. for event handling.
_Iob
I/O block for drivers
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
79 of 181
A4 : 2003-02

_Isr
Driver Interrupt Service Routine
_Jmp
Jump (for debugging)
_Jsr
Job Service Routine for drivers
_Len
Length
_Mir
Mirror Hardware register copy
_Msg
Message
_Msk
Mask
_Psr
Driver Power Fail Service Routine
_Req
Request Routine, e.g. a transmit request
_Ret
Function Return Label (for debugging)
_Stat
Status Flag
_Tbl
Table
_Tim
Time
_Tmr
Timer
_Tsk
Task
_Tsr
Driver Timeout Service Routine
Description
IOSA_tstIob EEPX__stPutCommand_Iob
An I/O block for PutCommand
byte EEPX__bDriver_Stat;
EEPROM driver status
byte EEPX__bWord_Ctr;
Word counter
word EEPX__wTimeout_Tmr;
Timeout timer
word EEPX__awAddress_Tbl[ 10 ];
Address Table
byte EEPX__bData_Len;
Length of data

Example identifiers
Justification
The module prefix represents some kind of namespace to avoid naming conflicts across modules. Scope, type
identifier and suffix provide essential information for those who can not reach it easily via development IDE,
because they must use external tools like debugger or symbol generator.
Examples
Here are some definitions from file EEPX1C1.C . The non-name part of the identifiers are printed in bold and
explained by comment. Name parts are printed italic. "allocation id." stands for "allocation identifier", which
is part of the type identifier.
EEPX_vSystemGlobalFunction(...);
Designed by
/* module prefix : EEPX
*/
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
80 of 181
A4 : 2003-02

/*
/*
/*
/*
scope
: 1 underscore = system wide
allocation id.: none
data type
: v = void
suffix
: none
*/
*/
*/
*/
EEPX__vModuleGlobalFunction(...);
/*
/*
/*
/*
/*
module prefix :
scope
:
allocation id.:
data type
:
suffix
:
EEPX
2 underscore = module wide
none
v = void
none
*/
*/
*/
*/
*/
typedef struct EEPX_tstBlock

{
/* ... */
} EEPX_tstBlock;
/*
/*
/*
/*
/*
module prefix :
scope
:
allocation id.:
data type
:
suffix
:
EEPX
1 underscore = system wide
t = typedef
st = struct
none
*/
*/
*/
*/
*/
/*
/*
/*
/*
/*
module prefix :
scope
:
allocation id.:
data type
:
suffix
:
EEPX
n = numeric constant
none
none
*/
*/
*/
*/
*/
typedef enum
{
EEPX_nSyntaxCmd,
EEPX_nSyntaxData
/* dito */
} EEPX_tenSyntax;
/*
/*
/*
/*
/*
module prefix :
scope
:
allocation id.:
data type
:
suffix
:
EEPX
t = type definition
en = enumeration
none
*/
*/
*/
*/
*/
/*
/*
/*
/*
/*
module prefix :
scope
:
allocation id.:
data type
:
suffix
:
EEPX
n = numeric constant
none
none
*/
*/
*/
*/
*/
#define EEPX_nExample 5
/*
/*
/*
/*
/*
module prefix :
scope
:
allocation id.:
data type
:
suffix
:
EEPX
1 underscore => system wide
n
none because it's a macro
none
*/
*/
*/
*/
*/
#define nu8Example (uint8) 3
/*
/*
/*
/*
/*
module prefix :
scope
:
allocation id.:
data type
:
suffix
:
none => module local

*/
0 underscore = module local */
n
*/
u8
*/
none
*/
typedef byte EEPX_tu8Example;
/*
/*
/*
/*
/*
module prefix :
scope
:
allocation id.:
data type
:
suffix
:
EEPX
t = typedef
u8 = uint8
none
*/
*/
*/
*/
*/
byte EEPX_u8Example;
/*
/*
/*
/*
module prefix :
scope
:
allocation id.:
data type
:
EEPX
none
u8
*/
*/
*/
*/

EEPX_nSyntaxData
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
81 of 181
A4 : 2003-02

/* suffix
: none
*/
IOSA_tstIob EEPX__stPutCommand_Iob
/*
/*
/*
/*
/*
module prefix :
scope
:
allocation id.:
data type
:
suffix
:
EEPX
none
st = struct
I/O block for PutCommand
*/
*/
*/
*/
*/
byte EEPX__u8Driver_Stat;
/*
/*
/*
/*
/*
module prefix :
scope
:
allocation id.:
data type
:
suffix
:
EEPX
none
u8
EEPROM driver status
*/
*/
*/
*/
*/
byte EEPX__u8Word_Ctr;
/*
/*
/*
/*
/*
module prefix :
scope
:
allocation id.:
data type
:
suffix
:
EEPX
none
u8
Word counter
*/
*/
*/
*/
*/
word EEPX__u16Timeout_Tmr;
/*
/*
/*
/*
/*
module prefix :
scope
:
allocation id.:
data type
:
suffix
:
EEPX
none
u16
Timeout timer
*/
*/
*/
*/
*/
word EEPX__au16Address_Tbl[ 10 ];
/*
/*
/*
/*
/*
module prefix :
scope
:
allocation id.:
data type
:
suffix
:
EEPX
none
au16 = array of uint16
Address Table
*/
*/
*/
*/
*/
byte EEPX__u8Data_Len;
/*
/*
/*
/*
/*
module prefix :
scope
:
allocation id.:
data type
:
suffix
:
EEPX
none
u8
Length of data
*/
*/
*/
*/
*/
QAC-Rules:--
3.1.17 Rule SMK502 | Mandatory

Avoid or enclose proprietary syntax. The general define to control proprietary syntax is _ANSI_CHECK_.
Justification
Usually proprietary syntax provides more control on the compiler output than ANSI C. This benefit conflicts with a
decrease in portability. To solve this conflict organize the code so that porting efforts are minimal.
Example
There is no general solution how to enclose compiler specific syntax. Here are some suggestions. You have to
choose one that fits closest to your needs.
1. Consider redesign such that ANSI C behaviour is closer to your needs.
For example, if you have performance problems due to many function entrances/exits in a deeply nested
hierarchy of function calls, consider hierarchy flattening prior to compiler specific inlining. As an additional benefit,
this should improve compiler output for other compilers, too.
2. Isolate compiler specific code sections in separate files. To port the code, copy them and adapt proprietary
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
82 of 181
A4 : 2003-02

syntax to a new compiler in these copies. Use the Preprocessor or configuration management tool to ensure that
only the correct version of the code is used in the project.
This should work always. It maps platform specifics to some #include statements or a checkout procedure. As a
drawback, maintanance is more difficult because several versions of the same code coexist. This procedure can
degenerate to independent versions of the same code if all code is compiler specific.
3. Directly enclose proprietary syntax in conditional compilation.
Small portion of proprietary syntax, e.g. exotic variable declarations can be encapsulated directly. In this case, the
proprietary syntax should be enclosed by additional compiler specific defines:
/* SWMOD
*/
#ifndef _ANSI_CHECK_
/* Use proprietary syntax for special controllers */
#if (ControllerType == CEVG1)
register int i;
/* Very rare optimisation only required on this */
/* controller/compiler
*/
#elif(ControllerType == VGC1)
....
#endif
#else
/* Use common declaration */
int i;
#endif
4. Move compiler specific information to compiler command line. Compilers may allow to pass some proprietary
information by code or command line. Latter is the best way to keep the code portable, but requires a defined
procedure how to keep this information linked with code. For example, names of inline functions may be listed as
compiler options, but these options must be archived in such a way that they can be restored easily from the CM
system. So far, this method has not been used.
5. Wrap keyword or keyword sequences by a macro.
It should be defined in a compiler specific header, e.g. cdef.h
/* cdef.h: */
#define INLINE __inline
/* inline keyword for multi2000 compiler */
/* SWMOD1c1.h: */
#include "cdef.h"
INLINE void f() { ....}
Wrap keyword or keyword sequence by file inclusion.

/* begin_inline.h : */
#pragma begin inline
/* end_inline.h : */
#pragma end inline
/* SWMOD1c1.h: */
#include "begin_inline.h"
void f()
{
...
}
#include "end_inline.h"
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
83 of 181
A4 : 2003-02

Note that this is the only way to enclose #pragma directives. Small helper files begin_inline.h and end_inline.h
are as compiler specific as cdef.h. This practise has not been used so far.
If proprietary keywords require additional parameters, it is unlikely to find a portable solution with 4 or 5. In
general, try to restrict the usage of non-standard compiler features to low level driver code and use strategy 2 to
provide some kind of hardware abstraction layer, so the problem is adressed more on the design level than the
code level. Note that there is no general out-of-the-box solution to this kind of problem.
Note: The _ANSI_CHECK_ define may not be confused with the _COMPILER_X86 define which is used to
control the simulation under MSVC and therefore relates to functional control flow, whereas _ANSI_CHECK_
encapsulates proprietary syntax e.g. to avoid warnings from the static code analysis or to allow compilation under
MSVC for improved warning information.
QAC-Rule: Logic
3.2
Basic-Set Misra
3.2.1 Environment
MISRA Rule 1: All code shall conform to ISO 9899 Standard C, with no extensions permitted.
ISO 9899 standard C is enforced implicitly with Level 9 and Level 8 messages. These messages are not all
individually registered against MISRA Rule 1. The messages which are explicitly registered against Rule 1 are all
related to language extensions; they are visible at level 4 in the Message Personality but are generated as Level
8 or 9. If it is necessary to use a particular language extension, it may be necessary to enable some of the
language extension options in QAC and to suppress some of the warnings shown under this rule. Language
extensions are permitted by the MISRA guidelines subject to raising appropriate documented deviations. Note
that some other MISRA Rules trap particular violations of the ISO language standard explicitly. Example Code:
#pragma PRQA_MESSAGES_OFF 3408
extern void test_001(void)
{
}
QAC-Rules: 0180, 0246, 0551, 0601, 0602, 1003, 1006, 1010, 1014, 1018 1022, 1026, 1027, 3664
0180
Lang_ext
[E] Use of ll for conversion specifier %s is a language extension.
The 'll' conversion specifier is an extension to ISO C.

#define LONGLONG (23LL)
#define ULONGLONG (49ULL)

static void f(void)

{
long long LL = LONGLONG;
unsigned long long ULL = ULONGLONG;
(void)printf("Lets output the values! %lld %llu", LL, ULL);
(void)scanf("Lets output the values! %lld %llu", &LL, &ULL);
LL = 0;
ULL = 0;
0246
Lang_ext
[E] Binary integer constants are a language extension.
Some compilers permit binary constants to be written in the format 0bnnn where nnn is a string of binary digits
(i.e. 0 and 1).
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
84 of 181
A4 : 2003-02

For example:
unsigned char uca = 0x1F;
unsigned char ucb = 0b00101110
0551
Lang_ext
/* Hex constant */
/* Binary constant - Message 246 */
[E] Cast may not operate on the left operand of the assignment operator.
It is illegal to attempt to cast the type of the type on the lhs. For example:
int main(void)
{
int
c = 0;
float ff = 20.0F;
float gg = 5.0F;
(char)c = ff * gg;
return 0;
}
0601
Lang_ext
[E] 'main()' should have either type 'int (void)' or 'int (int, char *[])'.
The ISO standard defines that the 'main' function will return an object of 'int' type and take either no arguments or
two arguments with the types listed above. i.e. the two legal alternatives follow:
int main(void) { /*...*/ }
or
int main(int argc, char* argv[]) { /*...*/ }
where 'argc' and 'argv' could have any names. Alternatives to this are not guaranteed portable.
0602
ISO_ExpU
int
main (void)
{
int __sigDefault;
int __sigIgnore;
int __sigError;
int _sigIgnore;
return 1;
}
1003
Lang_ext
/*
/*
/*
/*
warning 0602:
*/
prefix '__' reserved */
for library use
*/
OK */
[E] '#%s' is a language extension for in-line assembler.

If the in-line assembler extensions option is enabled, (-ex ASM), QAC will ignore all statements between a #asm
and a #endasm preprocessor directive. These directives are a language extension and will be flagged by
message 1003.
For example:
#asm
/* Message 1003 */
MOV DX, AX
XOR AX, 0x7F
#endasm
1006
/* Message 1003 */
Lang_ext
[E] This assembler construct has been ignored.
There are several ways in which in-line assembler code may be reconised within QAC. In all cases it is necessary
to specify the in-line assembler extensions option (-ex ASM) through the compiler personality. This message is
generated for the following constructs:
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
85 of 181
A4 : 2003-02

{
/* ... */
asm ("XOR DX, AX");
/* ... */
}
/* asm keyword in function call */
void asm doit (int value)

{
/* ... */
}
1010
Lang_ext
/* asm keyword in function declaration */
[E] Assuming '#%s' is extended '#if' preprocessor directive syntax.
Assuming '#%s' is extended '#if' preprocessor directive syntax.

1014
Lang_ext
[E] Unusual type specification - this will be treated as a language extension.
This is not a recognised data type in ISO C90 although some compilers may allow it as an extended data type.
1018
Lang_ext
[E] The LL suffix is a language extension.
The LL suffix is an extension to ISO C, and denotes literals of 'long long' type (also an extension to ISO C). This
is warning of the lack of portability to systems where 'long long' is not recognised as a type, and would constitute
a syntax error in code. For example:
static void foo(void)
{
long long a = 0LL;
a++;
}
1019
/* using non-portable LL suffix */
Lang_ext
[E] '@ address' is not supported in ISO C.
'@' is usually part of extended syntax, in embedded environments. This message warns that use of '@' is nonportable. For example:
#define POS
(0x10)

{
int test @ POS;
/* ... */
}

1020
Lang_ext
[E] '__typeof__' is not a valid ISO C token, and is treated as an extension.
'__typeof__' is usually part of extended syntax, seen in Gnu compiler. This message warns that use of
'__typeof__' is non-portable. For example:
{
int test = 0;
__typeof__(test) test1;
__typeof__(int) test2;
/* ... */
/* declaration of test1 as same type as test */

/* declaration of test2 as int */
1021
Lang_ext
[E] Statement in expression is not valid ISO, treated as an extension.
Statements within expressions are not allowed in ISO C. The following will compile in Gnu compiler:
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
86 of 181
A4 : 2003-02

{
/* unusual non-standard bracketing */
(
{
int b = 0;
b++;
}
);
}
1022
Lang_ext
[E] '__alignof__' is not a valid ISO C token, and is treated as an extension.
'__alignof__' is usually part of extended syntax, seen in Gnu compiler. This message warns that use of
'__alignof__' is non-portable. For example:
{
int test = 0;
test = __alignof__(char);
/* test receives byte alignment of char */
test = __alignof__(test);
/* test receives byte alignment of itself */
1026
Lang_ext
[E] The indicated @word construct has been ignored.
Some compilers use the @ character as a prefix to non-standard keywords that are C language extensions.
These words can be parsed by QAC by defining them away using " _munch_at" syntax. Message 1026 is
generated whenever a macro subsitiution of this form is generated. For example, by defining a macro
"tiny=_munch_at", QAC could be configured to accept a declaration of the form:
@tiny int x;
1027
/* Message 1026 */
Lang_ext
[E] long long is a language extension.
Type "long long" is not a valid integer type in the ISO 9899:1990 version of the C language and by default will be
parsed and treated as a synonym for type "long". All declarations of type long long or unsigned long long will
generate message 1027. "long long" is a valid type in the later ISO 9899:1999 language standard and QAC
supports the extended type in accordance with that definition if the language extension option "-ex longlong" is
enabled (Compiler Personality).
3664
Lang_ext
[E] Using a dot operator to access an individual bit is a language extension.
Some compilers support unorthodox data types which allow individual bits to be addressed using the symbol "."
as a special operator. Such code can usually be parsed by redefining the data type to a standard integer type
(using a configuration macro), but the bit selection operations will generate message 3664 For example:
unsigned int a;
a.1 = 0u;
/* Message 3664 */
3.2.2
Character Sets
MISRA Rule 5: Only those characters and escape sequences which are defined in the ISO C standard
shall be used.
C source code which fully conforms to the ISO C standard should contain only the set of characters defined in the
ISO standard. Use of any other characters may be supported by the implementation but will not necessarily be
portable to other environments.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
87 of 181
A4 : 2003-02

Example Code:
#include "misra.h"
/* An invalid include file name */
#include "abcde$.h"
/* MISRA Violation */
/* A non-conforming comment*/
/* PRLW */
/* A non-conforming macro */
#define MACA ABC$
extern void test_005a(void)

{
/*
PC
PC
PC
PC
PC
The basic source character set */

*pcuc = "ABCDEFGHIJKLMNOPQRSTUVWZYZ";
*pclc = "abcdefghijklmnopqrstuvwxyz";
*pcnu = "0123456789";
*pcg1 = "!\"#%&\'()*+,-./:";
*pcg2 = ";<=>?[\\]^_{|}~";
/*
PC
PC
PC
PC
PC
PC
PC
ISO-C
esa =
esb =
esf =
esn =
esr =
est =
esv =
Escape sequences */
'\a';
'\b';
'\f';
'\n';
'\r';
'\t';
'\v';
/* Numeric escape sequences */

PC esx = '\x0D';
PC es15 = '\15';

/*
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
Designed by
Non-conforming escape sequences */

esc = '\c';
esd = '\d';
ese = '\e';
esg = '\g';
esh = '\h';
esi = '\i';
esj = '\j';
esk = '\k';
esl = '\l';
esm = '\m';
eso = '\o';
esp = '\p';
esq = '\q';
ess = '\s';
esu = '\u';
esw = '\w';
esy = '\y';
esz = '\z';
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
88 of 181
A4 : 2003-02

}
extern void test_005b(void)
{
These characters are non-conforming */
*pc_36 = "$";
*pc_64 = "@";
*pc_96 = "`";
/*
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
And so
*pc128
*pc129
*pc130
*pc131
*pc132
*pc133
*pc134
*pc135
*pc136
*pc137
*pc138
*pc139
*pc140
*pc141
*pc142
*pc143
*pc144
*pc145
*pc146
are these */
= "";
= "";
= "";
= "";
= "";
= "";
= "";
= "";
= "";
= "";
= "";
= "";
= "";
= "";
= "";
= "";
= "";
= "";
= "";
PC
PC
PC
PC
PC
PC
PC
PC
PC
*pc161
*pc162
*pc163
*pc164
*pc165
*pc166
*pc167
*pc168
*pc169
=
=
=
=
=
=
=
=
=
"";
"";
"";
"";
"";
"";
"";
"";
"";
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
*pc170
*pc171
*pc172
*pc173
*pc174
*pc175
*pc176
*pc177
*pc178
*pc179
=
=
=
=
=
=
=
=
=
=
"";
"";
"";
"";
"";
"";
"";
"";
"";
"";
PC
PC
PC
PC
PC
PC
PC
*pc180
*pc181
*pc182
*pc183
*pc184
*pc185
*pc186
=
=
=
=
=
=
=
"";
"";
"";
"";
"";
"";
"";

/*
PC
PC
PC
Designed by
/*
/*
/*
/*
/*
/*
/*
/*
/*
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
*/
*/
*/
*/
*/
*/
*/
*/
*/
/*
/*
/*
/*
/*
/*
/*
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
Violation
Violation
Violation
Violation
Violation
Violation
Violation
*/
*/
*/
*/
*/
*/
*/
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
89 of 181
A4 : 2003-02

PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
*pc190
*pc191
*pc192
*pc193
*pc194
*pc195
*pc196
*pc197
*pc198
*pc199
=
=
=
=
=
=
=
=
=
=
"";
"";
"";
"";
"";
"";
"";
"";
"";
"";
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
*pc200
*pc201
*pc202
*pc203
*pc204
*pc205
*pc206
*pc207
*pc208
*pc209
=
=
=
=
=
=
=
=
=
=
"";
"";
"";
"";
"";
"";
"";
"";
"";
"";
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
*pc210
*pc211
*pc212
*pc213
*pc214
*pc215
*pc216
*pc217
*pc218
*pc219
=
=
=
=
=
=
=
=
=
=
"";
"";
"";
"";
"";
"";
"";
"";
"";
"";
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
*pc220
*pc221
*pc222
*pc223
*pc224
*pc225
*pc226
*pc227
*pc228
*pc229
=
=
=
=
=
=
=
=
=
=
"";
"";
"";
"";
"";
"";
"";
"";
"";
"";
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
*pc230
*pc231
*pc232
*pc233
*pc234
*pc235
*pc236
*pc237
*pc238
*pc239
=
=
=
=
=
=
=
=
=
=
"";
"";
"";
"";
"";
"";
"";
"";
"";
"";
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/

PC *pc187 = "";
PC *pc188 = "";
PC *pc189 = "";
PC *pc240 = "";
PC *pc241 = "";
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
90 of 181
A4 : 2003-02

PC
PC
PC
PC
PC
PC
PC
PC
*pc242
*pc243
*pc244
*pc245
*pc246
*pc247
*pc248
*pc249
=
=
=
=
=
=
=
=
"";
"";
"";
"";
"";
"";
"";
"";
/*
/*
/*
/*
/*
/*
/*
/*
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
*/
*/
*/
*/
*/
*/
*/
*/
PC
PC
PC
PC
PC
PC
*pc250
*pc251
*pc252
*pc253
*pc254
*pc255
=
=
=
=
=
=
"";
"";
"";
"";
"";
"";
/*
/*
/*
/*
/*
/*
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
Violation
Violation
Violation
Violation
Violation
Violation
*/
*/
*/
*/
*/
*/
QAC-Rules: 0235, 0285-0289

0235
ISO_ExpU
[U] Unknown escape sequence.
The escape sequence causing the parser warning does not correspond to those recognised by an ISO C
implementation. e.g. one such sequence could be as follows:
char c = '\/';
ISO C defines an escape sequence as being either a simple-escape-sequence, an octal-escape-sequence or a
hexadecimal-escape-sequence.
Simple escape sequences consist of the following - \', \", \?, \\, \a, \b, \f, \n, \r, \t, \v.
Octal escape sequences consist of a \ followed by up to three octal digits.
Hexadecimal escape sequences consist of a '\x' followed by any number of hexadecimal digits.
0285
ISO_ImplDef
[I] Character is not a member of the basic source character set.
The C language standard specifies a minimum character set. The handling of any characters outside this basic
set will amount to implementation defined behaviour. The basic set consists of the following characters:
Letters:
A
N
a
n
C
P
c
p
D
Q
d
q
E
R
e
r
F
S
f
s
G
T
g
t
H
U
h
u
I
V
i
v
J
W
j
w
Decimal digits
0 1 2
Graphic characters
! " # % &
; < = > ?
'
[
(
\
)
]
*
^
+
_

B
O
b
o
K
X
k
x
L
Y
l
y
M
Z
m
z
,
{
.
}
/
~
Others
0286
Designed by
Space character
Horizontal tab
Vertical tab
Form feed
ISO_ImplDef
[I] String literal contains character which is not a member of the basic source
character set.
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
91 of 181
A4 : 2003-02

Letters:
A
N
a
n
B
O
b
o
C
P
c
p
D
Q
d
q
E
R
e
r
F
S
f
s
G
T
g
t
H
U
h
u
I
V
i
v
J
W
j
w
Decimal digits
0 1 2
Graphic characters
! " # % &
; < = > ?
'
[
(
\
)
]
*
^
+
_
K
X
k
x
L
Y
l
y
M
Z
m
z
,
{
.
}
/
~
Others
Space character
Horizontal tab
Vertical tab
Form feed
0287
ISO_ImplDef
[I] Header name contains character which is not a member of the basic source
character set.
Letters:
A
N
a
n
B
O
b
o
C
P
c
p
D
Q
d
q
E
R
e
r
F
S
f
s
G
T
g
t
H
U
h
u
I
V
i
v
J
W
j
w
Decimal digits
0 1 2
Graphic characters
! " # % &
; < = > ?
'
[
(
\
)
]
*
^
+
_
K
X
k
x
L
Y
l
y
M
Z
m
z
,
{
.
}
/
~

Others
Space character
Horizontal tab
Vertical tab
Form feed
0288
ISO_ImplDef
[I] Source file '%s' has comments containing characters which are not members
of the basic source character set.
Letters:
A
N
a
n
Designed by
B
O
b
o
C
P
c
p
D
Q
d
q
E
R
e
r
F
S
f
s
G
T
g
t
H
U
h
u
I
V
i
v
J
W
j
w
K
X
k
x
L
Y
l
y
M
Z
m
z
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
92 of 181
A4 : 2003-02

Decimal digits
0 1 2
Graphic characters
! " # % &
; < = > ?
'
[
(
\
)
]
*
^
+
_
,
{
.
}
/
~
Others
Space character
Horizontal tab
Vertical tab
Form feed
0289
ISO_ImplDef
[I] Source file '%s' has preprocessing tokens containing characters which are
not members of the basic source character set.
Letters:
A
N
a
n
B
O
b
o
C
P
c
p
D
Q
d
q
E
R
e
r
F
S
f
s
G
T
g
t
H
U
h
u
I
V
i
v
J
W
j
w
Decimal digits
0 1 2
Graphic characters
! " # % &
; < = > ?
'
[
(
\
)
]
*
^
+
_
K
X
k
x
L
Y
l
y
M
Z
m
z
,
{
.
}
/
~
Others
Space character
Horizontal tab
Vertical tab
Form feed
3.2.3 Comments
MISRA Rule 9: Comments shall not be nested.
Message 3108 will identify an occurrence of the sequence "/*" within a comment but nested comments are not a
supported feature of the ISO C language and any attempt to code in this way will almost certainly precipitate
syntax errors. Example Code:
extern void test_009( void )

{
/* A /* MISRA */ Violation */
return;
QAC Rule: 3108

3108
Syntax
[S] Nested comments are not recognised in the ISO standard and should not be
used.
Nested comments are not a feature of ISO C. Some compilers will accept them, others will not. QAC does not
parse nested comments and generates message 3106 whenever it encounters the characters /* within a
comment. This is not in itself indicative of a syntax error but other syntax error warnings will probably follow if the
outer comment is terminated prematurely. For example:
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
93 of 181
A4 : 2003-02

/*
j=1; /* nested comment - message 3106 */
*/
3.2.4 Identifiers
MISRA Rule 11: Identifiers (internal and external) shall not rely on significance of more than 31
characters. Furthermore the compiler/linker shall be checked to ensure that 31 character significance and
case sensitivity are supported for external identifiers.
This rule is actually a relaxation of the requirements of ISO C.which states that external identifiers should be
distinct within 6 characters if the program is to be described as fully conforming and therefore portable. Example
Code:
#pragma PRQA_MESSAGES_OFF 3408 /* identifier is externally visible */
#include "misra.h"
void
void
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa1( void );
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa2( void );
extern S32 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb1;

extern S32 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb2;
/* 31 a's */
/* also 31 a's - MISRA Violation */
/* 31 b's */
/* also 31 b's - MISRA Violation */
S32 cccccccccccccccccccccccccccccc1;
S32 cccccccccccccccccccccccccccccc2;
/* 30 c's */
/* also 30 c's - OK */
extern S32 test_011(void)

{
S32 r;
S32 ddddddddddddddddddddddddddddddd1 = 0;
S32 ddddddddddddddddddddddddddddddd2 = 0;
/* 31 d's */
/* also 31 d's - MISRA Violation */

r = bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb1 +
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb2 +
cccccccccccccccccccccccccccccc1 +
cccccccccccccccccccccccccccccc2 +
ddddddddddddddddddddddddddddddd1 +
ddddddddddddddddddddddddddddddd2;
return(r);
QAC-Rules: 0777, 0779

0777
ISO_ExpU
[U] External identifier does not differ from other identifier(s) (e.g. '%s') within the
specified number of significant characters.
The ISO standard specifies that all external identifiers must be unique within the first 6 characters. Message 776
will be generated if this limit is breached.
Many development environments require more flexibility than this, and this message when external identifiers are
not distinct within a specified number of characters. This limit may be specified to QAC with the configuration
option -xnamelength (which may be applied through the compiler personality under GUI usage). A violation of this
limit will cause message 777 to be generated.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
94 of 181
A4 : 2003-02
0779
ISO_ExpU
[U] Identifier does not differ from other identifier(s) (e.g. '%s') within the
specified number of significant characters.
The ISO standard specifies that all identifiers must be unique within the first 31 characters. Message 778 will be
generated if this limit is breached.
Many development environments require more flexibility than this, and this message is generated when internal
identifiers are not distinct within a specified number of characters. This limit may be specified to QAC with the
configuration option -namelength (which may be applied through the compiler personality under GUI usage). A
violation of this limit will cause message 779 to be generated.
3.2.5 Types
MISRA Rule 14: The type char shall always be declared as unsigned char or signed char.
Example Code:
#include "misra.h"
typedef char
CH;
extern S32 test_014( void )

{
CH
*a = "AAAA";
char
*b = "Test";
unsigned char *c;
U8
*d;
signed char
*e;
S8
*f;
return(0);
}
QAC-Rule 3625
3625
Min_Decl
The type char should be declared explicitly as unsigned or signed char.
An object declared as plain char may be implemented as either a signed or an unsigned quantity. It is good
practice to be specific so as to reduce portability problems.
3.2.6 Constants
MISRA Rule 19: Octal constants (other than zero) shall not be used.
Example Code:

#include "misra.h"
{
S32 i;
S32 j;
S32 k;
PC buf[] = "ABC\15";
i = 0xFF;
j = 052;
k = '\15';
/* Hex is OK */
return(i+j+k);
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
95 of 181
A4 : 2003-02

}
QAC Rules: 0339, 3628

0339
Min_Const
The use of octal constants is not recommended.
Octal constants are distinguished from decimal constants only by having a leading zero. They are often prohibited
by programming standards because they can be so easily misinterpreted. The constant zero, 0, can strictly be
interpreted as an octal constant of zero but is considered an exception to this rule.
For example:
int x = 077;
int y = 0;
3628
/* octal constant not recommended */

/* zero is an exception */
Min_Const
Octal escape sequences shall not be used in character constants or string

literals.
Octal escape sequences shall not be used in character constants or string literals.
3.2.7 Declaration and Definition, Misra-Rules: 20, 21, 24, 25, 26, 29*
*= Supported with specified limitation for DAC.
MISRA Rule 20: All object and function identifiers shall be declared before use
A reference to an object which has not been declared is a language constraint error, and is therefore
automatically identifed as a MISRA violation under Rule 1. A reference to a function which has not been declared
is permissible in the C language.
Example Code:
#include "misra.h"
{
S32 r;
r = testf();
a020 = 0;
/* Constraint Error - MISRA Rule 1 Violation */
return(r);
}
QAC-Rule 3335
3335
Maj_Func
No function prototype. Implicit declaration inserted: 'extern int %s();'.

A function is being used for which there is no previous definition or prototype, and so in accordance with the ISO
standard an implicit declaration is being inserted. However it is not good practice to use functions without
providing a function prototype to define the interface.
This message is functionally equivalent to message 1302.
MISRA Rule 21: Identifiers in an inner scope shall not use the same name as an identifier in an outer
scope, and therefore hide that identifier.
Example Code:
#include "misra.h"
extern S32 var;
struct stag
{
S16 a;
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
96 of 181
A4 : 2003-02

S16 b;
};
extern S32 test_021a( void )
{
return(var);
}
extern S32 test_021b( void )
{
S32 var = 0;
return(var);
}
/*
Misra Violation
*/
extern S32 test_021c( void )

{
S32 ret = var;
return(ret);
}
extern S32 test_021d( S32 var ) /* MISRA Violation */
{
return(var);
}
extern S32 test_021e( S32 arg )
{
S32 ret;
ret = 0;
if (arg > 0)
{
S32 ret;
ret = test_021a();
}
return (ret);
}

extern void test_021f( void )

{
struct stag
{
S32 x;
S32 y;
} sl;
sl.x = 1;
return;
}
QAC-Rules: 2547, 3334

2547
Maj_array
Use of tag '%s' hides more global declaration.
This message is produced when a tag is used within an inner scope thereby causing the hiding of a declaration at
an outer level scope. This could be the result of using the same tag for a struct and a union, because there is only
a single namespace for all tags in the C language. If this is intentional, it is not good practice.
For example:
struct sT
{
/* ... */
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
97 of 181
A4 : 2003-02

};
/* ... */
void func(void)
{
union sT t;
/* ... */
}
/* Hides struct sT */
Check that your are picking up the right structure or union definition.
3334
Maj_Decl
This declaration of '%s' hides a more global declaration.
By declaring the specified identifier at this point you are obscuring an already visible identifier of the same name
for the remainder of this scope. Statements which depended upon the more global definition will now depend
upon the local definition. Hiding of identifiers is confusing and dangerous and should be avoided.
For example:
int value;
/* ... */
{
float value;
/* obscures earlier 'value' */
/* ... */
}
/* earlier 'value' comes back into scope */
/* ... */
MISRA Rule 24: Identifiers shall not simultaneously have both internal and external linkage in the same
translation unit.
This is specified as undefined behaviour in ISO C.
Example Code:
#pragma PRQA_MESSAGES_OFF 3408 /* identifier is externally visible */
#include "misra.h"
/*
Note that the rules by which linkage are defined were modified in
Technical Corrigendum 1 of the ISO C standard,
1. If the declaration of a file scope identifier for an object contains the
storage class specifier static, the identifier has internal linkage.
2. If the declaration of an identifier for an object or function contains
the storage-class specifier extern, if a prior declaration of that
identifier is visible and specifies internal or external linkage, the
linkage of the identifier at the latter declaration becomes the same
as the linkage specified at the prior declaration.
3. If the declaration of an identifier for an object or function contains

the storage-class specifier extern and there is no visible prior declaration
of the identifier, the identifier has external linkage.
4
If the declaration of an identifier for a function has no storage class

specifier, its linkage is determined exactly as if it were declared with
the storage class specifier extern.
5. If the declaration of an identifier for an object has file scope and no

storage-class specifier, its linkage is external.
*/
static S32 ah;
Designed by
/* Internal linkage (1) */
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
98 of 181
A4 : 2003-02

extern S32 ah;
extern S32 bh;

S32 bh;
/* External linkage (3) */

S32 ch;
extern S32 ch;

static S32 dh;

S32 dh;

/* External linkage (5) ***** MISRA Violation *****/
S32 eh;
static S32 eh;

/* Internal linkage (1) ***** MISRA Violation *****/
extern S32 fh;

static S32 fh;

extern S32 test_024( void );
static S32 test_024( void )

{
extern S32 a024;
static S32 a024 = 0;

extern S32 ah;
extern S32 bh;
return(1);
}
QAC-Rule 0625
0625
ISO_ExpU
[U] '%s' has been declared with both internal and external linkage - the
behaviour is undefined.
The variable has been declared at least twice with one of the declarations involving the static storage-class
qualifier. e.g.
int number;
static int number;

'number' is implicitly declared external through the first declaration and explicitly static through the second
declaration. Try and resolve this variable's linkage.
linkage - an identifier can have one of three types of linkage - external (defined outside this translation unit),
internal (defined for use within a particular translation unit) and none (denoting unique entities).
MISRA Rule 25: An identifier with external linkage shall have exactly one external definition.
This rule is enforced within a single translation unit by normal QAC analysis. It may be enforced within a project
by using the MCM Global Checks Report.
Example Code:
#include "misra.h"
S32 obj_025a = 3;
S32 obj_025b = 1;
S32 obj_025a = 4;
U32 obj_025b = 2;
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
99 of 181
A4 : 2003-02

QAC-Rules 0630, 5025
0630
ISO_ExpU
[U] More than one definition of '%s' (with external linkage).
A global object or function has been defined more than once in this file. It is legitimate to have multiple
declarations of the same identifier, but there should only ever be one definition.
For example:
int number=0;
/* ... */
int number=1;
5025
MISRA_Rule_25_Req_
An identifier with external linkage shall have exactly one external definition.
MISRA Rule 26: If objects or functions are declared more than once they shall have compatible
declarations.
At a single file level, QAC enforces this rule through Rule 72
To apply complete coverage of this rule, it is necessary to run the MCM Global Checks report on your project.
This will check for violations of Rule 26 project-wide. The global test will check that all declarations and definitions
of functions or variables with external linkage have the same type.
Note: The global test will not pick up static variables. These will be picked up by QAC messages.
Example Code:
#include "misra.h"
static S32 i;
static F32 i;
extern S8 buf[10];
extern S32 test_026a ( S16 a )
{
extern U8 buf[10];
extern F32 far[10];
const S16 r = 1;
return ( r );
}
extern void test_026b ( void )
{
extern F64 far[10];
}

QAC-Rules: 0626, 0627, 0628, 5026

0626
ISO_ImpU
[u] '%s' has different type to previous declaration (which is no longer in scope).
Two declarations for the same global identifier are in conflict. The declarations occur in different scopes but are
inconsistent. The behaviour is implementation defined.
For example:
void foo1(void)
{
extern int glob;
/* ... */
}
void foo2(void)
{
extern long glob;
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
100 of 181
A4 : 2003-02

/* ... */
}
0627
Constraint
[C] '%s' has different type to previous declaration in the same scope.
Two declarations of the same identifier are in conflict. Both declarations have been made at the same scope.
Note that it is possible and legitimate (although unwise) to hide an identifier with a different declaration at an inner
scope. For example:
int figure;
/* ... */
/* ... */
long figure;
0628
Constraint
[C] '%s' has different type to previous in-scope declaration.
This has a different type to a previous declaration of the same variable. Although it is legal in C to redeclare a
variable, the type has to be the same. It is illegal to redeclare with a different type in the same scope. For
example:
int foo(void);
int i;
char c;
long i;
char foo(void);
int main(void)
{
extern char i;
int x;
char cc = 1;
i = 0;
c = 'a';
boo();
if (cc) {
long x = 1L;
x++;
}
return (int)i;
/* different type to previous decl */

/* different type to previous in-scope decl */
/* function undeclared */
/* hides a more global decl */

float foo(int a)
{
volatile char a = '\0';
return (float)a + 1L;
}
void boo(void)
{
return;
}
/* different type to previous out-of-scope decl */
Change the name of the redeclared items or simply remove the redeclared items if the declaration is redundant.
Also do not declare a variable that hides a another object of the same name. Not only is this very confusing and
prone to misuse, some tools handle variable visibility differently especially when leaving inner scope blocks.
5026
Designed by
MISRA_Rule_26_Req_
If objects or functions are declared more than once they shall have
compatible declarations.
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
101 of 181
A4 : 2003-02

MISRA Rule 29: The use of a tag shall agree with its declaration.
The use of a tag must agree with its declaration. In the example below, a struct is defined with the tag "record"
and it is subsequentially reused in the definition of a union. This is illegal in ISO C. For example:
struct record
{
int
number;
};
/* ... */
union record
<\PRE>
decimal;
The tag 'record' has been defined for a structure and then is used with the union
keyword.
Example Code:
#include "misra.h"
struct mytaga
{
S32 i;
S32 j;
S32 k;
} ;
struct mytagb
{
S32 i;
S32 j;
S32 k;
} ;
struct mytagc
{
S32 i;
S32 j;
S32 k;
} ;
static enum mytagb {tom, dick, harry};

extern void test_029 (void)

{
struct mytaga st1 = {10, 11};
initialised to 0 */
struct mytagb st2 = {10, 11, 12, 13};
union mytagc un1 = { 1, 2, 3 };
}
/* Not desirable, but legal, other gets

QAC-Rule: 0547
0547
ISO_ExpU
[U] This declaration of tag '%s' conflicts with a previous declaration.
The specified tag declaration conflicts with a previous declaration. For example the same tag identifier cannot be
used to define both a structure and a union. There is one namespace for all structure, union and enum tags.
For example:
struct record
{
int number;
};
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
102 of 181
A4 : 2003-02

union record decimal;
/* Message 547 */
3.2.8 Initialization
MISRA Rule 32: In an enumerator list, the '=' construct shall not be used to explicitly initialise members
other than the first, unless all items are explicitly initialised.
The MISRA rule permits three ways of initialising the members of an enum list:
1. None are initialised.
2. Only the first is initialised.
3. All are initialised.
Example Code:
#include "misra.h"
#define VAL 4294
{
enum game
{ tennis = 2, cricket, golf, hurling };
enum town
/* OK */
{ London, Paris, New_York };
/* OK */
enum country {Germany = 1, Italy = 2, Australia = 3};
/* OK */
enum color
{ red, blue = VAL, green };
enum cars
{ BMW, Mercedes, Ford = VAL };
/* MISRA Violation
*/
return(0);
}
QAC-Rule 0723
0723
Min_Enum
Initialise none, first only, or all entries in this enumerator list.
Different coding standards make a variety of demands on the way in which enum constants may be initialised. This message
suggests that either first enum, all enums, or none of the enums should be explicitly initialised. For example:
enum colours
{
red,
green = 4,
blue = 5
} col;
/* prohibited: first enum not initialised */
enum colours
{
red = 1,
green = 4,
blue = 5
} col;
/* OK: all enums initialised */
enum colours
{
red = 3,
green,
blue
} col;
/* OK: only first enum is initialised */
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
103 of 181
A4 : 2003-02

3.2.9 Operators, Misra Rules: 33*, 34, 35, 36, 37*, 42
*= Supported with specified limitations for DAC
MISRA Rule 33*: The right hand operand of a && or || operator shall not contain side effects.
Example Code:
#include "misra.h"
extern S16 test_033a(S16 x);
extern S16 test_033b( S16 a, S16 b )
{
S16 r;
if ( (a > 1) && ( (b++) < 0) )
{
r = 1;
}
if ( (b > 0) || ( test_033a(a) != 0 ) )
{
r = 1;
}
r = (( a > 0 ) ? (b) : (b++));
/* OK */
r = (( a > 0 ) ? (--b) : (b));
/* OK */
return r;
}
QAC-Rule 3415
3415
Maj_SideEff
The right hand operand of '&&' or '||' has side effects.
The right hand operand of the && operator is only evaluated if the left hand operand evaluates to "true". The right hand
operand of the || operator is only evaluated if the left hand operand evaluates to "false". In either case, it can be confusing if
side effects are conditional on the left hand operand. It may be better practice to use an explicit test to control this behaviour.
For example:
/* ... */
if ((w==y) && ((x=fn())==z))
/* ... */
x is only assigned the return value of 'func' if 'w==y' evaluates to true.

MISRA Rule 34: The operands of a logical && or || shall be primary expressions.
Rule 47 partially enforces this rule.
Example Code:
#include "misra.h"
extern S16 test_034( S16 x, S16 y, S16 z, S16 ishigh, const S16 *pr)
{
S16 r = 0;
r = ( x == 0 ) && !(ishigh == 1);
r = ( x == 0 && ishigh != 0);
r = ((++x) != 0) && (ishigh != 0);
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
104 of 181
A4 : 2003-02

r = *pr && (x == 0);
r = x && y && z;
r = x && y || z;
return(r);
}
QAC-Rule 3400
3400
Min_Stmt
The operands of a logical && or || operator shall be primary expressions
An operand of a && and || operator, should always be logical expression or an object expressing a Boolean
value. The C language does not recognise a Boolean type but a number of operators return a Boolean value
expressed as an integer. In order to avoid confusion, it is safer if the operands of && and || operators are primary
expressions, i.e. an identifier, a literal constant or a parenthesised expression. For example:
r = a && b && c;
r = a || b || c;
r = (a > 200) && c;
r = a && b || c;
r = a || b && c;
r = a > 200 && c;
r = !a && b;
r = !a || b;
r = *pi || b;
r = a || !b;
r = a || *pi;
/* Message 3400 */
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
OK */
OK */
OK */
Message
Message
Message
Message
Message
Message
Message
3400
3400
3400
3400
3400
3400
3400
*/
*/
*/
*/
*/
*/
*/
MISRA Rule 35: Assignment operators shall not be used in expressions which return Boolean values.
Example Code:
#include "misra.h"
extern S32 test_035a( S32 x, S32 i )
{
S32 r = 0;

if ( x = i )
{
r = 1;
}
if ( (x = i) != 0 )
{
r = 1;
}
while ( (x += 2) < 0)
{
++x;
}
return(r);
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
105 of 181
A4 : 2003-02

QAC-Rule 3326
3326
Min_Stmt
Assignment operators shall not be used in boolean expressions.
The C language does not include a Boolean type but a number of operators return a boolean value (0/1) and
various control expressions use an arithmetic value in a boolean sense. These are the types of expression which
QAC classes as boolean. Message 3326 is generated if any assignment (=) or compound assignment (+=, -=
etc.) operator is present in such an expression. For example:
if (fp = fopen("filename", "r")) != NULL)
/* Message 3326 */
...
if (i += j) ++r;
/* Message 3326 */
MISRA Rule 36: Logical operators should not be confused with bitwise operators.
QAC can flag variations of possible misuse of logical and bitwise (arithmetic) operators.
Example Code:
#include "misra.h"
extern S32 test_036(
S32 x,
S32 y,
S32 a,
S32 b,
S32 c,
S32 d )
{
S32 r;
r = (a<b) &
r = (a<b) |
r = (a+b) &&
r = (a+b) ||
r = (a+b) &&
r = (a+b) &&
r = (a+b) ||
r = (a>b) &&
r = a
&&
r = (a>b) ||
r = !(a+b);
return(r);
(c>d);
(c>d);
(c+d);
(c+d);
(c>d);
c;
(c>d);
(c+d);
(c+d);
(c+d);
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
MISRA
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
Violation
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
QAC Rules: 4101, 4102, 4106 4110

4101
Maj_Ops
Both operands of & bitwise AND operator are "boolean" expressions.
Two expressions of "boolean" type are the operands of a & bitwise AND operator . This is probably a mistake; the
&& logical AND operator was probably intended.
For example:
x = (a > b) & (c > d);
4102
Maj_Ops
/* Message 4101 */
Both operands of | bitwise OR operator are "boolean" expressions.
Two expressions of "boolean" type are the operands of a | bitwise inclusive OR operator . This is probably a
mistake; the || logical OR operator was probably intended.
For example:
x = (a > b) | (c > d);
/* Message 4102 */
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
106 of 181
A4 : 2003-02

4106
Maj_Ops
Both operands of && logical AND operator are "arithmetic" expressions.
Two expressions of arithmetic type are the operands of a && logical AND operator. This is probably a mistake; the
bitwise AND operator, & was probably intended.
For example:
x = (a + b) && (c + d);
4107
Maj_Ops
/* Message 4106 */
Both operands of || logical OR operator are "arithmetic" expressions.
Two expressions of arithmetic type are the operands of a || logical OR operator. This is probably a mistake; the
bitwise OR operator, |, was probably intended.
For example:
x = (a + b) || (c + d);
4108
Maj_Ops
/* Message 4107 */
Left hand operand of logical operator is an "arithmetic" expression.
An expression of arithmetic type is the left hand operand of a logical operator. This is probably a mistake.
For example:
x = (a + b) && (c > d);
4109
Maj_Ops
/* Message 4108 */
Right hand operand of logical operator is an "arithmetic" expression.
An expression of arithmetic type is the right hand operand of a logical operator. This is probably a mistake.
For example:
x = (a > b) && (c + d);
4110
Maj_Ops
/* Message 4109 */
Logical negate operator applied to an "arithmetic" expression.
An expression of arithmetic type is the operand of a ! logical negation operator. This is probably a mistake.
For example:
x =!(a + b);
/* Message 4110 */
MISRA Rule 37: Bitwise operations shall not be performed on signed integer types.
Example Code:
#include "misra.h"

extern S32 test_037( S32 x, U8 y )

{
x = x << 2;
x = x >> 1;
x = x & 3;
x = x | 5;
x = ~x;
y
y
y
y
y
=
=
=
=
=
y << 2;
y >> 1;
y & 3;
y | 5;
~y;
return(x);
QAC-Rules 0502, 4130, 4131
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
107 of 181
A4 : 2003-02

0502
Min_Ops
A right shift on signed data may be an arithmetic or a logical shift.
Right shift operations on signed operands are implementation defined. In a logical shift, the left hand bits are
replaced with zeroes; in an arithmetic shift the left hand bits are replaced by replicating the sign bit. In addition the
format of negative integers is not defined by the ISO standard (although in practice it is usually a two's
complement format).
A special situation arises when unsigned char and unsigned short objects are the operands of a shift operator.
The rules of integer promotion require that these objects are usually promoted to signed int before the shift, and
so internally the operation is performed on a signed data type even though the underlying data is unsigned. QAC
does not generate message 502 when the immediate operand is unsigned but there are some more complex
unsigned expressions in which the message is generated as an indirect result of integral promotion.
Note that the shifting right of a negative twos-complement integer may not produce the same result as a division
by two. The result of dividing the value -5 by 2 can be implemented as -2 remainder -1, or as -3 remainder 1. An
arithmetic right shift will aways yield the value -2.
For example:
/* ... */
int
sia;
unsigned char uca;
sia = sia >> 3;
sia = uca >> 2;
/* ... */
4130
/* Message 502 */
/* No message */
Maj_Ops
Bitwise operations on signed data will give implementation defined results.
It is not usually appropriate to perform bitwise operations (e.g. |, &, ^ , ~) on signed data types. The internal
representation of negative integer numbers is not defined (although it is usually two's complement), and therefore
it is not wise and not portable to manipulate "signed" data with bitwise operators.
A special situation arises when unsigned char and unsigned short objects are the operands of a bitwise operator.
The rules of integer promotion require that these objects are usually promoted to signed int before the bitwise
operation, and so internally the operation is performed on a signed data type even though the underlying data is
unsigned. QAC does not generate message 4130 when the immediate operand is unsigned but there are some
more complex unsigned expressions in which the message is generated as an indirect result of integral
promotion.
For example:

void func (
int sia,
unsigned char uca,
unsigned char ucb
)
{
/* ... */
sia = sia & 0x7F7F;
sia = uca | ucb;
}
4131
/* Message 4130 */
/* No message */
Min_Ops
Left shift operation on signed operand.
It is not good practice to use shift operations on signed data. The internal representation of negative integer
numbers is not defined (although it is usually two's complement), and therefore it is not wise and not portable to
manipulate "signed" data with shift operators.
A special situation arises when unsigned char and unsigned short objects are the operands of a shift operator.
The rules of integer promotion require that these objects are usually promoted to signed int before the shift, and
so internally the operation is performed on a signed data type even though the underlying data is unsigned. QAC
does not generate message 4131 when the immediate operand is unsigned but there are some more complex
unsigned expressions in which the message is generated as an indirect result of integral promotion.
e.g.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
108 of 181
A4 : 2003-02

void func (
int sia,
unsigned char uca,
)
{
...
sia = sia << 3;
sia = uca << 2;
/* Message 4131 */
/* No message */
MISRA Rule 42: The comma operator shall not be used, except in the control expression of a for loop.
This rule doesn't prevent the use of the comma operator in a for loop; however if the comma operator is used in a
for loop, it is likely to violate Rule 66 Example Code:
#include "misra.h"
#define A (-5)
#define B 3
{
S16 x = 0;
S16 y = 0;
S16 i;
y = ( x = A, x + B );
for (i = 0, ++y; i < B; ++i)

{
++y;
}
/* OK */
for (i = 0, y = 0; i < B; ++i)

{
++y;
}
/* OK */
return(y);
}
QAC-Rules 3417
3417
Min_Ops
The comma operator should be avoided. It is better practice to use separate

statements.

Don't use the comma operator simply to avoid creating two statements. The comma operator makes code less
readable and therefore less maintainable.
The comma operator is most frequently used in for loop headers. Message 3417 is not generated in the for loop
context; message 3418 is generated instead. For example:
a = (b++, c++);
b++;
a = c++;
/* Message 3417 */
/* Separate statements are clearer */
for (i=0; i < 10; ++i, ++j)

{
...
Designed by
/* Message 3418 */
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
109 of 181
A4 : 2003-02

3.2.10 Conversions
MISRA Rule 45: Type casting from any type to or from pointers shall not be used.
Implicit conversions between pointers are not permitted in the C language and any attempt to do such a
conversion constitutes a language constraint error (Rule 1). This MISRA rule is concerned with disallowing casts
which involve pointers. Casts between function pointer types are included in the scope of this rule but are
specifically addressed by Rule 105.
A fundamental danger with pointer casts is attempting to cast a pointer to a type which has a stricter alignment
requirement. This might occur when casting a char * to an int * if the char * pointer may reside on any byte
boundary, but an int * is constrained to alignment on a 4 byte boundary. Casting from an int * to a char *,
however, would be safe.
If the requirements of this rule are to be relaxed in any way, it may be sensible to disable QAC message number
310. The configuration will then still warn against casts between, for example, integers and pointers but will
permit casts between different pointer types providing they are "safe" under the conditions described above. If
you wish to modify the configuration in this way, It is particularly important that QAC is configured to specify the
correct alignment restrictions and size of all datatypes. Example Code:
/***********************************************************
| Integer |Object Pointer|Function Pointer|
-----------------|---------|--------------|----------------|
Integer
|
nnn
|
306
|
306
|
Object Pointer
|
306
|
310
|
307
|
Function Pointer |
306
|
307
|
* 313 *
|
-----------------|---------|--------------|----------------|
***********************************************************/
#include "misra.h"
struct X;
extern void (* pf)( S32 * );
extern S32
e045a;
extern S8
c;
extern S32 test_045 (
const
S32 * pci,
volatile S32 * pvi,
const
S8 * pcc,
struct X
* ps )
{
S32 *pi;

/* Casting to an object type */

e045a = (S32) pci;
e045a = (S32) pf;
/* Casting to an object pointer type */

pcc
pci
pcc
pcc
pcc
=
=
=
=
=
(S8*) pci;
(S32 *) pcc;
(S8*) e045a;
(S8*) ps;
(S8*) pf;
/*
/*
/*
/*
/*
MISRA
MISRA
MISRA
MISRA
MISRA
Violation
Violation
Violation
Violation
Violation
*/
*/
*/
*/
*/
/* Casting to a function pointer type */

pf = (void (*)( S32 *)) pci;
pf = (void (*)( S32 *)) c;
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
110 of 181
A4 : 2003-02

/* Casting away type qualifiers */
pi = (S32 *)pci;
pi = (S32 *)pvi;
return(0);
}
QAC-Rules: 0306, 0307, 0308, 0310, 0311, 0312, 3305

0306
ISO_ImplDef
[I] Cast between pointer and integral type is implementation defined.
It is dangerous to cast to and from integers as the implementation defines the size of the integer required and the
result of the cast. This could result in a loss of information. The exception is the casting of integer value zero
which will produce a NULL pointer.
0307
ISO_ImpU
[u] This cast is not defined for pointers.
The ISO standard only defines certain casts involving pointers. Others, like the casting of a pointer to a float, are
undefined and therefore not portable.
There are two situations under which casting between pointers of different types is safe. Those are:
0308
Min_Ops
Non-portable cast involving pointer to an incomplete type.
ISO says that any cast from a complete to an incomplete type is undefined. Check that the target object has been
defined completely. Perhaps you are missing an include file or you have misspelt the object name. e.g.
struct x;
int i;
struct x * ptr;
p = (struct x*)&i;
attempts to take the address of 'i' and convert it to an address of an incomplete type.
incomplete type - any type which describes an object for which information required to determine its
size is missing.
0310
Min_Ops
Casting to different object pointer type.
You are casting a pointer to another pointer type. This is often disallowed in programming standards,
by reason of safety, portability, and readability. For example:
void function(char *string, int *number)

{
int * pi;
char * pc;
pc = (char *)number;
pi = (int *)string;
/* Message 310 */
/* Message 310 & 3305 */
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
111 of 181
A4 : 2003-02

0311
Maj_Ops
Dangerous pointer cast results in loss of const qualification.
that volatile qualification has been lost from the object pointed to. For example:
int
*pi;
const
int
*pci;
...
pi = pci;
pi = (int *)pci;
...
0312
Maj_Ops
/* Ptr. to int
/* Ptr to con. int
*/
*/

/* Message 311 */
Dangerous pointer cast results in loss of volatile qualification.
that volatile qualification has been lost from the object pointed to. For example:
int
*pi;
volatile int
*pvi;
...
pi = pvi;
pi = (int *)pvi;
/* Ptr. to int
/* Ptr to volatile int
*/
*/

/* Message 312 */
...
3305
Maj_Ops
Pointer cast to stricter alignment.
This message is generated whenever a pointer is cast to a pointer type which has a "stricter" alignment
requirement. The alignment of types in memory is implementation defined, but it is a common requirement, for
example, for an int to be allocated on a 2 byte boundary while a char can be allocated at any memory address. In
this case it would be safe to cast an "int *" to a "char *", but could be dangerous to cast a "char *" to and "int *";
such an operation could lead to a memory access exception error.
QAC provides an option to specify the implemented alignment constraints and the generation of message 3305
will respect these settings.

/* ... */
char *pc;
/* 1 byte aligned */
int *pi;
/* 2 byte aligned */
long *pl;
/ 4 byte aligned */
/* ... */
pi = (int*)pc;
/* Message 3305 */
pc = (char *)pl;
/* OK */
/* ... */
3.2.11 Expressions, Misra-Rules 46, 49, 50

MISRA Rule 46: The value of any expression shall be independent of the order of its evaluation.
Example Code:
#include "misra.h"
extern S32 test_046a(S32 *p);
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
112 of 181
A4 : 2003-02

extern S32 test_046b(S32 *p);
extern S32 test_046c(const S32 *p);
extern void test_046d(S32 x, S32 y, const S32 buf[], S32 max)
{
/***********************************************************************/
/* 0400 '%s' is modified more than once between sequence points
*/
/*
- evaluation order undefined.
*/
/***********************************************************************/
x = y + (x++);
/***********************************************************************/
/* 0401 '%s' may be modified more than once between sequence points
*/
/*
*/
/***********************************************************************/
/* This message is generated in situations where it is not certain that
an object is modified more than once but the passing of a pointer to
that object suggests it may be */
y = test_046a(&x) + (x++);
y = test_046a(&x) + test_046b(&x);
/* MISRA Violation
/* MISRA Violation
*/
*/
/* In this case the order of the increment and assignment ARE NOT defined */
x = (x > max) ? (++x) : 0;
/* In this case the order of the increment and assignment ARE NOT defined */
x = (y > max) ? (++x) : 0;
/* In the following statement, there is a sequence point after the
evaluation of the first operand of the ternary operator, so "x"
is known to be incremented before the assignment occurs. The
code may be silly, but it is not undefined */
x = ((++x) > max) ? 0 : 1;
/* OK
*/

/* In these statements, any modification to the value of x by the function

test_046a is known to occur before the assignment and therefore, although
"x" may be modified more than once, the order of evaluation is not undefined */
x = test_046a(&x);
/* OK
*/
x = (y > max) ? test_046a(&x) : 0;
/* OK
*/
/* The prototype of test_046c declares a "pointer to const S32" parameter and

so there is no possibility of x being modified more than once */
y = test_046c(&x) + (x++);
/* OK
*/
/***********************************************************************/
/* 0402 '%s' is modified and accessed between sequence points
*/
/*
*/
/***********************************************************************/
y = (x + 6) / (x++);
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
113 of 181
A4 : 2003-02

y = buf[x] + (x++);
/* MISRA Violation
*/
y = (x > max) ? (x++) : 0;
/* OK
*/
/***********************************************************************/
/* 0403 '%s' may be modified and accessed between sequence points
*/
/*
*/
/***********************************************************************/
y = test_046a(&x) + x;
/* MISRA Violation
*/
y = buf[x] + test_046a(&x);
/* MISRA Violation
*/
/* The prototype of test_046c declares a "pointer to const S32" parameter and
so there is no possibility of x being modified */
y = test_046c(&x) + x;
/* OK
*/
y = buf[x] + test_046c(&x);
/* OK
*/
}
QAC-Rules: 0400, 0401, 0402, 0403
0400
ISO_ExpU
[U] '%s' is modified more than once between sequence points - evaluation
order undefined.
An object is being modified more than once between sequence points. The ISO standard indicates that the
evaluation order in this case is undefined; i.e. you cannot guarantee that one object modification happens before
another - only that all modifications will be complete at the next sequence point. For example:
x = 2;
y = 3;
x = y * x++;
/* Message 400 */
In the above example the variable x may acquire the value 6 or the value 7.
0401
ISO_ExpU
[U] '%s' may be modified more than once between sequence points - evaluation
order undefined.
There is a possibility (although not certainty) in this statement that an object may be modified more than once
between sequence points. The ISO standard indicates that the evaluation order in this case is undefined; i.e. you
cannot guarantee that one object modification happens before another - only that all modifications will be
complete at the next sequence point. For example:

x = func(&x);
i = ((x==0) ? ++i : i);
0402
ISO_ExpU
/* Message 0401 */
/* Message 0401 & 3415 */
[U] '%s' is modified and accessed between sequence points - evaluation order
undefined.
An object is being used and also modified between sequence points. The ISO standard indicates the evaluation
order in this case to be undefined. i.e. you cannot guarantee if the modification will take place before or after it is
used. For example:
if (a[++index] == a[index])
In the above example you might consider the order of evaluation to be as it reads from left to right. This would
lead you to believe that this the condition would always evaluate to TRUE. However, if evaluation order was from
right to left then no such assumption can be made. Two ISO certified compilers could conceivably generate
different results in this case.
0403
Designed by
ISO_ExpU
[U] '%s' may be modified and accessed between sequence points - evaluation
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
114 of 181
A4 : 2003-02

order undefined.
The variable may have its value both used and updated between sequence points. It is not certain that this will
occur, perhaps because it depends on some conditionally-executed code. Because the order of evaluation of
expressions between sequence points is unspecified, it is impossible to know if the variable will be modified
before or after is has been used. For example:
if (a[val==0 ? ++index : index] == a[index])
The variable 'index' may or may not be modified depending upon the value of the 'val' variable. If it is modified,
the value of the right hand side of the expression may be evaluated before or after 'index' is modified.
Reliance on the order of evaluation in such cases is very dangerous and non-portable.
MISRA Rule 49: Tests of a value against zero should be made explicit, unless the operand is effectively
Boolean.
QAC issues a warning when the test expression in a control statement does not include at top level an operator
which provides a "Boolean" result, e.g. for:
if (x)
but not for:
if (!x)
Example Code:
#include "misra.h"
extern S32 test_049( S32 i )
{
S32 r = 0;
S32 j;
j = i ? 2 : 3;
if ( i + j )
{
r = 2;
}
if ( !i )
{
r = 3;
}
/* OK */

if ( i )
{
r = 1;
}
if ( i > j )
{
#if 1
r = 4;
#endif
}
if ( i = 1 )
{
r = 5;
}
Designed by
/* OK */
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
115 of 181
A4 : 2003-02

return(r);
}
QAC-Rule 3344
3344
Min_Stmt
Testing a value should be made explicit.
Avoid using control expression with implicit comparisions against 0. It is better to express a control expression
with an explicit relational operator (<, <=, >, >=) or an equality operator (==, !=). This is often required by
programming standards and makes code more readable.
For example:
if (a)
/* Message 3344 */
if (a + b) /* Message 3344 */
if (!b)
/* Message 3344 */
if
if
if
if
((a + b)==0) /* OK */
(a > b) /* OK */
(a == b) /* OK */
(b != 0) /* OK */
MISRA Rule 50: Floating point variables shall not be tested for exact equality or inequality.
Example Code:
#include "misra.h"
extern S32 test_050( F64 x, F64 y )
{
S32 r = 0;
if (x == y)
{
r = 1;
}
if (x != y)
{
r = -1;
}
return(r);
QAC-Rule 3341
3341
Maj_Ops
Comparing floating point expressions for equality (with '==' or '!=') is unlikely to
give predictable results and should be avoided.
Comparing floating point numbers can be very dangerous due to problems with precision.
...
double a;
...
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
116 of 181
A4 : 2003-02

if (a ==0.0)
{
...
}
If the value of 'a' is not exactly zero this could cause many problems. Some compilers may only check to a certain
number of decimal places, making the above expression true although 'a' is not strictly zero. The value of 'a' may
be so small that for your needs you would want it to act as zero but the compiler treats it as a value not equal to
zero. Avoid using floating point values for comparisons.
3.2.12 Control Flow, Misra-Rules 53*, 56, 57, 58, 59, 61, 62, 64, 65
*= Supported with specified limitation for DAC
MISRA Rule 53: All non-null statements shall have a side-effect.
Example Code:
#include "misra.h"
extern S32 test_053a(S32 n);
extern void test_053b( S32 x, const S32 *p, const volatile S32 *pv )
{
S32 n = 0;
n = n;
x > 0, --x;
x = 0, x + 1;
n;
*p++;
*pv++;
/* Rule 47 Violation */
(x > 0) ? (++n) : n;
(n) && (test_053a(n));
(test_053a(n)) && n;
return;
QAC-Rules: 3110, 3112, 3404, 3425, 3426, 3427

3110
Maj_SideEff
The left-hand operand of this ',' has no side-effects.
The left hand side of a comma operator is evaluated for its side effects only, and does not affect the value of the
expression. In this case, the left hand side has no side effects and is therefore redundant. Removing it would
make the expression more readable. e.g.
for(i, j = strlen(s) - 1; i < j; i++, j--)
....
The 'i' in the first expression is redundant and could be removed.

3112
Designed by
Maj_SideEff
This statement has no side-effect - it can be removed.
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
117 of 181
A4 : 2003-02

The specified statement does no work - it has no effect on the state of the program - therefore the parser
recommends you discard it.
...
i;
...
/* not a declaration so it changes nothing */
Unused statements add to program complexity just by being there - adding lines to the program and causing
readers to puzzle over its presence.
Like variables which are no longer used, this statement should be removed.
Note that this can also occur if the parser detects syntax errors previously.
3404
Maj_Stmt
*p++ means *(p++) not (*p)++. The * operator is redundant.
The increment operator has higher precedence than the pointer operator and so this expression is equivalent to
"*(p++)". If p is not a pointer to a volatile, the * operator is redundant and the expression is equivalent to "p++".
3425
Maj_SideEff One side of ':' expression has no side effect.
One side of the ':' operator has side-effects, and the other doesn't. This is unusual programming, and QAC is
warning as such, in case it represents an outcome that the programmer did not intend. For example:
{
unsigned int a = 0U;
unsigned int b = 0U;
a ? b : b++;
a ? b++ : b;
/* rhs of ':' has no side-effect */

/* lhs of ':' has no side-effect */
3426
Maj_SideEff
Right hand side of comma expression has no side effect and its value is not
used.
If the right hand operand of a comma expression has no side effect and it value is not used the meaning of the
statement must be questioned. For example:
i = 1, j + 1;
/* Message 3426 */
n = (i = 1, j + 1);
3427
Maj_SideEff
/* OK */
Right hand side of logical operator has no side effect.

When using a dependent chain technique, one of the operands has no side effect (perhaps should have been
increment or decrement operators). Was this intended? The following example displays the message:
{
unsigned int a = 0U;
unsigned int b = 0U;
a++ && b;
/* 'b' has no side-effect, did you intend this? */
b++;
}
MISRA Rule 56: The goto statement shall not be used.
Example Code:
#include "misra.h"
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
118 of 181
A4 : 2003-02

{
goto mylabel;
mylabel:
return(0);
}
QAC-Rule 2001
2001
Min_Ctrl
'goto' statements should be avoided.
Any program that uses a 'goto' statement can be rewritten to give the same effect without using 'goto'. Amend
your code to eliminate this diagnostic.
Note also that backward jumps contribute to the number-of-backward-jumps (STBAK) metric and jumps out of
control structures will contribute to the knot count (STKNT) metric. Experience suggests that these metrics are
often well correlated with subsequent difficulty in testing and maintenance.
MISRA Rule 57: The continue statement shall not be used.
Example Code:
#include "misra.h"
{
S16 r = 0;
S16 n = 0;
for ( n = 0; n < 5; n++ )
{
if ( n > 2 )
{
continue;
}
++r;
}

r = 1;
return(r);
QAC-Rule 0770
0770
Min_Ctrl
A continue statement should not be used.
It is better to avoid 'continue' statements as far as possible. Programming standards often include this
recommendation. For example:
while (gi != 0)
{
gi++;
if (gi == MAX_VALUE)
{
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
119 of 181
A4 : 2003-02

continue; /* Message 769 */
}
/* ... */
}
MISRA Rule 58: The break statement shall not be used (except to terminate the cases of a switch
statement).
Example Code:
#include "misra.h"
extern S32 test_058( S32 x, S32 y )
{
S16 n = 0;
for (n = 0; n < 5; n++)
{
if (n>2)
{
break;
}
}
switch ( x )
{
case 1:
n = 1;
break;
case 2:
if (y > 0)
{
break;
}
n = 2;
break;
default:
n = 0;
break;
}
return(0);
QAC-Rules: 0769, 3333

0769
Min_Ctrl
A break statement shall only be used in a switch statement.
It is good style to avoid 'break' statements as far as possible except in switch statements. Programming
standards often include this recommendation. Message 769 will be generated whenever a break statement is
encountered within a loop statement but outside a switch statement. For example:
while (gi != 0)
{
gi++;
if (gi == VALUE)
{
break;
/* Message 769 */
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
120 of 181
A4 : 2003-02

}
}
3333
Min_Ctrl
A break statement shall only be used at the end of all the statements in a switch
case block.
Break statements should be avoided as far as possible except in switch statements. Any break in control flow
increases complexity which can affect maintainability and reliability. A 'break' can usually be avoided - perhaps by
making the loop termination condition dependent upon a continuation flag. Message 3333 is functionally similar to
message 769 - but is generated only in the context of an if statement within a switch construct. For example:
switch(n)
{
case 1:
if (flag == 0)
break;
/* Message 3333 */
...
break;
case 2:
...
MISRA Rule 59: The statements forming the body of an if, else if, else, while, do ... while or for statement
shall always be enclosed in braces.
Example Code:
#include "misra.h"
extern S16 test_059( S16 x )
{
S16 n = 0;
for (n = 0; n < 5; n++)
x = 2;
for (n = 0; n < 5; n++) x = 2;
if (n == 2)
n = 3;
else
n = 2;

if (n == 5) n = 6;
else n = 7;
while (n < 5)
n++;
while (n < 5) n++;
do
n++;
while (n<9);
do n++; while (n<9);
if (n != 0)
if (n > 0)
{
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
121 of 181
A4 : 2003-02

x = 1;
}
else
{
x = 2;
}
return(x);
}
QAC-Rules: 2212, 2214, 3402

2212
Min_Brace
Braces should be used in control statements, even when the body has only one
statement.
It is good programming practice to enclose the body of a control statement within braces even when there is only
one statement. By using braces you will create a visible grouping of statements. Programming errors can be
caused when the body of a control statement without braces is expanded from one statement to many. If single
statements were brace-enclosed from the start then the adding of new statements will avoid this common source
of problems.
Note that message 2214 is generated for the special case when the body of the control loop occurs on the same
line as the control statement.
For example:
/* ... */
if (n > 0)
++x;
/* Message 2212 */
if (n > 0) ++x;
if (n > 0)
{
++x;
}
2214
/* Message 2214 */
/* OK */
Min_Brace
Braces should be used in control statements, even when the body has only one
statement.
It is good programming practice to enclose the body of a control statement within braces even when there is only
one statement. By using braces you will create a visible grouping of statements. Programming errors can be
caused when the body of a control statement wihtout braces is expanded from one statement to many. If single
statements were brace enclosed from the start then the adding of new statements will avoid this common source
of problems.
Message 2214 is generated when the body of the control loop occurs on the same line as as the control
statement. Message 2212 is generated when the body of the control loop occurs on a separate line.
For example:
/* ... */
if (n > 0) ++x;
if (n > 0)
++x;
/* Message 2212 */
if (n > 0)
{
++x;
}
3402
Designed by
/* Message 2214 */
/* OK */
Min_Brace
Braces should be used to clarify the structure of this 'if'-'if'-'else' statement.
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
122 of 181
A4 : 2003-02

The absence of braces (and correct indentation) can be misleading, particularly where there are nested control
statements. Code which is difficult to read is difficult to maintain. Braces should be used.
For example:
if (i > j)
if (j > 0)
i = j;
else
i = 0;
It may not be clear to the reader whether the 'else' belongs to the inner or outer 'if' statement. Use braces and
correct indentation to make it clear that the 'else' belongs to the inner 'if'.
MISRA Rule 61: Every non-empty case clause in a switch statement shall be terminated with a break
statement.
Example Code:
#include "misra.h"
extern S32 test_061( S32 n )
{
S32 x = 0;
switch (n)
{
case 0:
/* OK */
case 1:
x = 1;
break;
/* OK */
case 2:
x = 2;
/* OK */
case 3:
x = 4;
default:
break;
}
return(x);
QAC-Rule 2003
2003
Min_Switch
A non-empty 'case' or 'default' should end with an explicit 'break' or 'return'

statement.
It is not considered good practice to allow one case to fall through to the next in a switch statement unless the
first case contains no statements of its own, i.e. both cases are processed in the same way.
For example:
switch (value)
{
case ONE:
/* some statements - but no 'break'
so it 'falls through' to the next case */
case TWO:
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
123 of 181
A4 : 2003-02

/* ... */
break;
case THREE:
case FOUR:
/* ... */
break;
default:
break;
}
/* fall through allowed */
Fall through is invariably overlooked when reviewing switch statements where the cases themselves are
separated by statements. This can lead to unexpected results. It is probably better to group the two or more
cases together and provide conditional code within the last case to make it clear that code is shared. At the very
least you should comment the 'fall through' in order to draw attention to it.
for example:
switch (value)
{
case ONE:
case TWO:
if (value == ONE)
{
/* case ONE specific statements */
}
/* ... */
break;
/* ... */
}
MISRA Rule 62: All switch statements should contain a final default clause.
Example Code:
#include "misra.h"
extern S32 test_062( S32 n )
{
S32 x = 0;
switch (n)
{
default:
x = 7;
break;
case 2:
x = 5;
break;
case 3:
x = 6;
break;
}

switch (n)
{
case 0:
x = 0;
break;
case 1:
x = 1;
break;
}
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
124 of 181
A4 : 2003-02

return(x);
}
QAC-Rules: 2002, 2009

2002
Min_Switch
No 'default' case found in this 'switch' statement.
In the interests of safety and reliability you should always include a 'default', catch all, case even if you know you
have catered for all possible cases.
2009
Min_Switch
The default case label shall be placed last within a switch block.
The "default" case label is usually positioned at the end of a switch block. To position it elsewhere is likely to
cause confusion.
MISRA Rule 64: Every switch statement shall have at least one case.
Example Code:
#include "misra.h"
{
S32 n = 0;
S32 x = 0;
switch (n)
{
default:
x=2;
break;
}
return(x);
}
QAC-Rule 3315
3315
Min_Switch
This 'switch' statement contains only a single path - it is redundant.
A switch statement with only a default clause is a redundant construct. e.g.

switch(n)
{
default:
i=1;
break;
}
/* no case statements */
MISRA Rule 65: Floating point variables shall not be used as loop counters.
Example Code:
#include "misra.h"
extern S32 test_065( F32 m )
{
F32 n;
S32 x = 0;
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
125 of 181
A4 : 2003-02

for (n = 0.0F; n < m; n++)
{
++x;
}
return(x);
}
QAC-Rule 3340
3340
Min_Ctrl
Floating point 'for' loop index. This should be replaced by an integral type.
QAC identifies a "control variable", by examining the loop control statements. The use of a floating variable is
unconventional and should be avoided.
3.2.13 Functions, Misra-Rules: 68, 69, 70*, 72, 73, 75, 76, 78, 79, 80, 82, 83, 84
MISRA Rule 68: Functions shall always be declared at file scope.
Example Code:
#include "misra.h"
{
extern void f(void);
f();
return(0);
}
QAC-Rule 3221
3221
Min_Decl
Functions shall not be declared at block scope.
Function declarations are permitted at block scope level, i.e. within a function, by the ISO standard, but good
practice dictates that they should always be placed at file scope and preferably within a header file. For example:
void foo(int a) { extern int myfunc(int x); /* Message 3221 */ int r; r = myfunc(a); ... }
MISRA Rule 69: Functions with variable numbers of arguments shall not be used.
Example Code:

#include "misra.h"
extern void test_069a(S32 n, ...);
extern void test_069b(S32 x, ...);
extern S32 test_069c( void )

{
test_069a(2, "tom", "dick");
test_069b(1, "harry");
return(0);
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
126 of 181
A4 : 2003-02

extern void test_069b(S32 x, ...)
{
}
QAC-Rule 5069
5069
MISRA_Rule_69_Req_ Functions with variable numbers of arguments shall not be used.
MISRA Rule 70*: Functions shall not call themselves, either directly or indirectly:
To apply complete coverage of this rule, it is necessary to run the MCM Global Checks report on your project.
This will check for violations of Rule 70 Project wide. The global test recursively descends down each function,
seeing if it calls itself along any of its potential call paths. The global test returns the first circular path it comes
across. QAC checks for a function calling itself.
Example Code:
#include "misra.h"
extern
extern
extern
extern
extern
extern
void
void
void
void
void
void
test_070a(void);
test_070b(void);
test_070c(void);
test_070d(void);
test_070e(void);
test_070f(void);
extern void test_070a(void)

{
test_070b();
test_070f();
}
extern void test_070b(void)
{
test_070c();
}
extern void test_070c(void)
{
test_070d();
}

extern void test_070d(void)

{
test_070e();
}
extern void test_070e(void)
{
test_070b();
}
extern void test_070f(void)
{
test_070f();
}
QAC-Rules: 3670, 5070

3670
Designed by
Maj_Func
Recursive call to function containing this call.
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
127 of 181
A4 : 2003-02

The function is recursive. Recursive functions can be dangerous, in that they have the potential to go into infinite
loops. Use the relationships browser in order to see more complicated function call orders which may lead to
recursive behaviour.
int fib(int n)
{
/* this is a safe recursive function or is it? fib(-1)!*/
if (n==0 || n==1)
{
return 1;
}
return fib(n-1)+ fib(n-2);
}
5070
MISRA_Rule_70_Req_
Functions shall not call themselves, either directly or indirectly:
MISRA Rule 72: For each function parameter the type given in the declaration and definition shall be
identical, and the return types shall also be identical.
Note: Part of this implementation is the same as Rule26 (Messages 626-628).
Example Code:
#include "misra.h"
extern S32 test_072a( S32 x );
extern F32 test_072a( S32 x )
{
int r;
r
r
r
r
=
=
=
=
test_072b(x);
test_072b(x, x + 1);
test_072c(x, x + 1);
test_072d(x, x + 1);
/*
/*
/*
/*
Rule 20 VIolation
MISRA Violation
MISRA Violation
MISRA Violation
*/
*/
*/
*/
return(0.0F);
}
extern S32 test_072c( S32 m );

extern S32 test_072d( S32 y )

{
return(0);
}
QAC-Rules 1331, 1332, 1333
1331
Maj_Func
Type or number of arguments doesn't match previous use of the function.
This message will only be generated whan a function is being called in the absence of a prototype. It is always
advisable to use function prototypes consistently throughout your source code; but be aware that it can be
dangerous to use them in some places but not in others. When functions are called in the absence of a prototype,
arguments of type char, short and float are subject to default argument promotion. For example:
int r;
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
128 of 181
A4 : 2003-02

int a;
long b;
/* ... */
r = foo(a);
r = foo(b);
r = foo(a, b);
1332
/* Function call with no previous prototype */

/* Message 1331 */
/* Message 1331 */
Maj_Func
Type or number of arguments doesn't match prototype found later.
This message will only be generated whan a function is being called in the absence of a previous prototype or
function definition. It is always advisable to use function prototypes consistently throughout your source code.
Function prototypes are best located in header files and should always be positioned before any function calls. It
can be dangerous to use them in some places but not in others. When functions are called in the absence of a
prototype, arguments of type char, short and float are subject to default argument promotion.
For example:
{
int r;
int a;
/* ... */
r = foo(a);
prototype */
/* ... */
}
extern int foo ( long a );
*/
1333
/* Type of argument conflicts with subsequent
/* Prototype conflicts with previous usage of function
Maj_Func
Type or number of arguments doesn't match function definition found later.
This message will only be generated whan a function is being called in the absence of a previous prototype or
function definition. It is always advisable to use function prototypes consistently throughout your source code,
even and especially when the source file contains the function definition. Function prototypes are best located in
header files and should always be positioned before any function calls. It can be dangerous to use them in some
places but not in others. When functions are called in the absence of a prototype, arguments of type char, short
and float are subject to default argument promotion.
For example:
{
int r;
int a;
/* ... */
r = foo(a);
/* ... */
/* Type of argument conflicts with subsequent prototype */

int foo ( long a )

{
/* ... */
/* Prototype conflicts with previous usage of function */
MISRA Rule 73: Identifiers shall either be given for all of the parameters in a function prototype
declaration, or for none.
Example Code:
#include "misra.h"
extern S32 test_073a(U8 * x, U8 * y);
Designed by
/* OK */
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
129 of 181
A4 : 2003-02

extern S32 test_073b(U8 *, U8 *);
extern S32 test_073c(U8 * x, U8 *);
/* OK */
QAC-Rule 0652
0652
ISO_ImpU
[u] Identifiers should be given for all or none of the parameters in a function
prototype.
The ISO standard requires that, in a function prototype, all of the parameters should be specified as types only or
all parameters be specified named. For example:
static void a(int y, int); /* Illegal */
MISRA Rule 75: Every function shall have an explicit return type.
Example Code:
#include "misra.h"
extern test_075a ( U32 x );

{
return(0);
}
extern test_075c ( void )
{
return(1);
QAC-Rule 2050
2050
Min_Decl
The 'int' type specifier should not be omitted from function declarations.
This function declaration does not explicitly specify a type. This results an an implicit 'int' type for the declaration.
This is a legitimate practice in C, but is not recommended for reasons of clarity and readability.
extern foo(void);
/* Message 2050 */
MISRA Rule 76: Functions with no parameters shall be declared with parameter type void.
Example Code:
#include "misra.h"

extern void test_076a ();

{
return(0);
}
extern void test_076a()
{
}
QAC-Rule 1303
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
130 of 181
A4 : 2003-02

1303
Maj_Func
An empty parameter list in a function type has a different meaning in C++.
In C, function declarations with an empty parameter list are an obsolescent way of declaring a function and it
leaves the number of arguments required by the function undefined. It is bad practice to define functions like this
in a modern ISO C environment where a function interface can be defined with a full prototype. If a function is
defined as having no parameters, the parameter list should be specified with the single keyword "void".
In C++, a function declaration with an empty parameter list is defined to mean that the function takes no
parameters. Always use '(void)' if the function has no parameters.
Old style function declarations should be avoided because they also have other hazards in the way that
arguments are handled because they introduce the mechanism of "default argument promotion".
MISRA Rule 78: The number of parameters passed to a function shall match the function prototype.
Example Code:
#include "misra.h"
extern void test_078a( S32 i, S32 j );
extern void test_078b( S32 k );
extern void test_078c( void )
{
test_078a( 1 );
test_078b( 1, 1 );
return;
}
QAC-Rules: 0422, 0423, 3319

0422
Constraint
[C] Function call contains fewer arguments than prototype specifies.
A function is called with fewer arguments than the prototype specifies. This is a language constraint violation and
is very dangerous as it may lead to corruption of the stack. For example:
int foo(int a, int b);
...
ret = foo(x);
0423
Constraint
/* func call with few arguments */
[C] Function call contains more arguments than prototype specifies.
To call a function with more arguments than the prototype specifies is a language constraint violation. The extra
arguments are not used. For example:
int foo(int a, int b);

...
ret = foo(x, y, z);
3319
/* func call with too many arguments */
ISO_ExpU
[U] Function called with number of arguments which differs from number of
arguments of definition.
A function should be called with the same number of arguments as the definition. Calling functions with a different
number of arguments from the definition leads to undefined bahaviour. Possible exceptions are functions with a
prototype ending in an ellipsis (,...) such as printf() which can be called with a variable number of arguments.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
131 of 181
A4 : 2003-02

This message is only generated when the function definition is provided by an old style function header. If the
interface has been defined with a full prototype or ISO header, message 422 or 423 will be generated instead.
For example:
static int boo();
int foo(p, a, lng)
char *p;
int a;
long lng;
{
return (*p + a + (int)lng);
}
int main(void)
{
int ret;
ret = foo("hello", 2);
(void)boo(21);
ret = foo("hello", 3, 10L, "hi");
(void)boo();
return ret;
/*
/*
/*
/*
fewer args than definition */

function not defined */
more args than definition */
func called with variable nbr of args */
MISRA Rule 79: The values returned by void functions shall not be used.
Example Code:
#include "misra.h"
extern void test_079a(S32 n);
{
S32 i = 0;
i = test_079a(1);
return(i);

QAC 0543
0543
ISO_ExpU
[U] 'void' expressions have no value and may not be used in expressions.
The (nonexistent) value of an expression of type void cannot be used in any way, and implicit or explicit
conversions (except to void) cannot be applied to such an expression. For example:
extern void foo(void);
...
if ( foo( ) == 0)
/* Message 543 */
{
...
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
132 of 181
A4 : 2003-02

MISRA Rule 80: Void expressions shall not be passed as function parameters.
This rule is implicitly enforced through Rule 79
Example Code:
#include "misra.h"
extern void test_080a( S32 a );
extern S32 test_080b( S32 b );
extern void test_080c( S32 x )
{
test_080a((void)test_080b(0));
/* MISRA Violation through Rule 79. */
return;
}
QAC 0541
0541
ISO_ImpU
[u] Argument no. %s does not have object type.
All arguments to a function call must be expressions of object type. For example struct T1 below is an incomplete
type and hence cannot be used as a parameter. For example:
struct T1 f1(struct T1 p1);
static int f2(struct T1 p1)
{
return f1(p1);
}
MISRA Rule 82: A function should have a single point of exit.

Example Code:
#include "misra.h"
extern S32 test_082a(S16 i)
{

if (i > 0)
{
return(0);
}
else
{
return(1);
}
QAC-Rule 2006
2006
Min_Func
'%s()' has more than one 'return' path.
Good programming practice should produce structured functions with one entry and one exit. More than one exit
point indicates a forced break in control flow and, like any break in control flow, leads to code which is more
difficult to read and maintain. Note that one of the return paths referred to in this message may be an implicit
"return;" statement at the end of the function.
void func(void)
{
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
133 of 181
A4 : 2003-02

if (...)
{
...
return;
/* break out of function */
}
...
/* remaining skipped statements */
}
/* normal exit point */
By restructuring the code it is always possible to create a 'one entry - one exit' function.
MISRA Rule 83: Functions with non-void return type shall have: i) one return statement for every exit
branch (including the end of the program), ii) each return shall have an expression, iii) the expression
shall match the return type.
Example Code:
#include "misra.h"
extern enum Fruit {Lemon= -1, Orange=1, Apple=3} fruit;
extern enum Days {Monday=8 , Tuesday=6, Wednesday=4, Thursday=1} weekdays;
extern enum Colors {Red , Blue, Green} color;
extern S32 test_083a(S32 i)
{
S32 r;
/* MISRA Violation - No return statement */
r = i + 2;
}
extern S32 test_083b(S32 j)
{
S32 r;
r = j + 2;
return;
/* MISRA Violation - No expression in return statement */

extern S32 test_083c(void)

{
F32 f = 1.0F;
return (f);
/* MISRA Violation - Return expression has wrong type */
extern enum Colors test_083d(S32 n)

{
switch (n)
{
case 1:
return Wednesday;
case 3:
return 0;
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
134 of 181
A4 : 2003-02

case 4:
return fruit;
case 6:
return n;
default:
return Red;
}
}
extern S32 test_083e(void)
{
return Red;
}
QAC-Rules: 0744, 0745, 1403, 1413, 1423, 1433, 1443, 3900 3913, 3915, 3917, 3919 - 3923, 3925, 3927,
3929 3936, 3938, 3940 3948, 3950, 3952 3960, 3962 3972, 3974 4007, 4010 4019, 4021 4034,
4037, 4039, 4040, 4043, 4047, 4048, 4050 4081
0744
ISO_ExpU
[U] '%s()' has been declared with a non void result type but ends with an implicit
'return ;' statement.
This function has been explicitly defined as having a non-void return type but ends with an implicit return
statement which returns no value. This will always return an undefined value. e.g.
float func(void)
{
/* no return statement */
}
0745
ISO_ExpU
[U] 'return;' found in '%s()', which has been defined with a non-'void' return type.
This return statement has no return expression although a non-void return type for the function has been defined.
The value returned by the function is undefined. e.g.
float func(void)
{
/* ... */
return;
}
1403
Min_Enum
Return of constant enum not in enum type.

You are returning an enum constant not from this enum type. While legal, this could represent maintainability and
readability problems. Following are examples of potential issues in usage of enum constants from other enum
types:
typedef enum _SIZE
{
small,
medium,
large
} SIZE;
typedef enum _COLOUR
{
red,
green,
blue,
yellow
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
135 of 181
A4 : 2003-02

} COLOUR;
static int foo(SIZE container)
{
return 0;
}
static SIZE test(SIZE box)
{
if (box < blue)
/*
{
box = red;
/*
}
else if (box == red) /*
{
foo(green);
/*
}
return blue;
/*
}
1413
Min_Enum
comparison with other enum constant */

assignment of other enum constant */
equality comparison with other enum constant */
argument passed is other enum constant */
return of other enum constant */
Return of numeric constant when enum expected.
You are returning a numeric constant from a function declared with an enum type. This is legitimate but not good
practice.
typedef enum _SIZE
{
small,
medium,
large
} SIZE;
SIZE test(void)
{
...
return 2;
}
1423
/* Message 1413 */
Min_Enum
Return of enum object of different type.
You are returning an object of different enum type. While legal, this could represent maintainability and readability
problems. Following are examples of potential issues in usage of objects of different enum types:

typedef enum _SIZE

{
small,
medium,
large
} SIZE;
{
red,
green,
blue,
yellow
} COLOUR;
{
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
136 of 181
A4 : 2003-02

return 0;
}
{
COLOUR paper = blue;
if (box < paper)
{
box = paper;
}
else if (box == paper)
{
foo(paper);
}
return paper;
/* comparison with other enum object */

/* assignment of other enum object */
/* equality comparison with other enum object */
/* argument passed is other enum object */
/* return of other enum object */
1433
Min_Enum
Return of enum to non enum type.
You are returning an enum object when non enum type is expected. While legal, this could represent
maintainability and readability problems. Following are examples of potential issues in usage of enum objects in
place of other types:
typedef enum _SIZE
{
small,
medium,
large
} SIZE;
{
red,
green,
blue,
yellow
} COLOUR;
static int foo(int container)
{
return 0;
}

static int test(int box)

{
COLOUR paper = blue;
if (box < paper)
{
box = paper;
}
{
foo(paper);
}
return paper;
/* comparison with enum object */

/* assignment of enum object */
/* equality comparison with enum object */
/* argument passed is enum object */
/* return of enum object */
1443
Designed by
Min_Enum
Return of non enum type to enum, and may be out of range.
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
137 of 181
A4 : 2003-02

You are returning a non enum type when enum object is expected. While legal, this could represent
maintainability and readability problems. Also, the value of this type could be outside the range of the enum.
Following are examples of potential issues in usage of non enum types in place of enum objects:
typedef enum _SIZE
{
small,
medium,
large
} SIZE;
{
red,
green,
blue,
yellow
} COLOUR;
{
return 0;
}
{
int paper = 0;
if (box < paper)
{
box = paper;
}
{
foo(paper);
}
return paper;
/* comparison between non enum type and enum object */

/* assignment of non enum object */
/* equality comparison between non enum type and enum object */
/* argument passed is non enum object */
/* return of non enum object */
3900
Maj_Pchar
char value returned from signed char %s().

3901
Maj_Pchar
char value returned from unsigned char %s().

3902
Maj_Pchar
'char' value returned from 'short %s()'.

3903
Designed by
Maj_Pchar
char value returned from unsigned short %s().
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
138 of 181
A4 : 2003-02

3904
Maj_Pchar
'char' value returned from 'int %s()'.

3905
Maj_Pchar
char value returned from unsigned int %s().

3906
Maj_Pchar
'char' value returned from 'long %s()'.

3907
Maj_Pchar
char value returned from unsigned long %s().

3908
Maj_Pchar
char value returned from float %s().

3909
Maj_Pchar
char value returned from double %s().

3910
Maj_Pchar
char value returned from long double %s().

3911
Maj_Pchar
unsigned char value returned from char %s().

3912
Maj_UStoS
unsigned char value returned from signed char %s().

Implicit casts should be avoided. An unsigned value is being converted to a signed type - the result may be
negative.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
139 of 181
A4 : 2003-02

3913
Maj_UStoLS
unsigned char value returned from short %s().

3915
Maj_UStoLS
unsigned char value returned from int %s().

3917
Maj_UStoLS
unsigned char value returned from long %s().

3919
Maj_ItoFL
unsigned char value returned from float %s().

3922
Maj_Pchar
signed char value returned from char %s().

3923
Maj_StoUS
signed char value returned from unsigned char %s().

3925
Maj_StoUS
signed char value returned from unsigned short %s().

3927
Maj_StoUS
signed char value returned from unsigned int %s().


3929
Maj_StoUS
signed char value returned from unsigned long %s().

3930
Maj_ItoFL
signed char value returned from float %s().

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
140 of 181
A4 : 2003-02

3931
Maj_ItoFL
signed char value returned from double %s().

3932
Maj_ItoFL
signed char value returned from long double %s().

3933
Maj_Pchar
short value returned from char %s().

information. The result of a conversion to or from a plain 'char' datatype will depend on whether the plain 'char'
datatype is signed or unsigned. This is implementation defined behaviour and it is not wise to make any
assumptions.
3934
Maj_Small
short value returned from signed char %s().

When a value is converted to a smaller type and the result cannot be represented the result will depend on the
implementation.
3935
Maj_StoUS
short value returned from unsigned char %s().

When a value is converted to a smaller type the result depends on the implementation.e.g.
unsigned char
fn (
)
{
short x;
return x;
}
3936
Maj_StoUS
short value returned from unsigned short %s().
A value of type short is being returned from a function that is defined with type unsigned short.


{
short ret;
/* ... */
return(ret);
}

values.
3938
Maj_StoUS
short value returned from unsigned int %s().
A value of type short is being returned from a function that is defined with type unsigned int.
{
short ret;
/* ... */
return(ret);
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
141 of 181
A4 : 2003-02

}

values.
3940
Maj_StoUS
short value returned from unsigned long %s().
A value of type short is being returned from a function that is defined with type unsigned long.
{
short ret;
/* ... */
return(ret);
}

values.
3941
Maj_ItoFL
short value returned from float %s().
A value of type short is being returned from a function that is defined with type float.
float foo ( void )
{
short ret;
/* ... */
return(ret);
}

3942
Maj_ItoFL
short value returned from double %s().
A value of type short is being returned from a function that is defined with type double.
double foo ( void )
{
short ret;
/* ... */
return(ret);
}


3943
Maj_ItoFL
short value returned from long double %s().
A value of type short is being returned from a function that is defined with type long double.
{
short ret;
/* ... */
return(ret);
}

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
142 of 181
A4 : 2003-02

3944
Maj_Pchar
unsigned short value returned from char %s().
A value of type unsigned short is being returned from a function that is defined with type char.
char foo ( void )
{
unsigned short ret;
/* ... */
return(ret);
}

3945
Maj_UStoS
unsigned short value returned from signed char %s().
A value of type unsigned short is being returned from a function that is defined with type signed char.
{
unsigned short ret;
/* ... */
return(ret);
}

3946
Maj_Small
unsigned short value returned from unsigned char %s().
A value of type unsigned short is being returned from a function that is defined with type unsigned char.
{
unsigned short ret;
/* ... */
return(ret);
}

3947
Maj_UStoS
unsigned short value returned from short %s().

A value of type unsigned short is being returned from a function that is defined with type short.
short foo ( void )
{
unsigned short ret;
/* ... */
return(ret);
}

3948
Maj_UStoLS
unsigned short value returned from int %s().
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
143 of 181
A4 : 2003-02

3950
Maj_UStoLS
unsigned short value returned from long %s().

3952
Maj_ItoFL
unsigned short value returned from float %s().
A value of type unsigned short is being returned from a function that is defined with type float.
float foo ( void )
{
unsigned short ret;
/* ... */
return(ret);
}
3953
Maj_ItoFL
unsigned short value returned from double %s().
A value of type unsigned short is being returned from a function that is defined with type double.
double foo ( void )
{
unsigned short ret;
/* ... */
return(ret);
}

3954
Maj_ItoFL
unsigned short value returned from long double %s().
A value of type unsigned short is being returned from a function that is defined with type long double.
{
unsigned short ret;
/* ... */
return(ret);
}


3955
Maj_Pchar
int value returned from char %s().
A value of type int is being returned from a function that is defined with type char.
char foo ( void )
{
int ret;
/* ... */
return(ret);
}

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
144 of 181
A4 : 2003-02
3956
Maj_Small
int value returned from signed char %s().
A value of type int is being returned from a function that is defined with type signed char.
{
int ret;
/* ... */
return(ret);
}

3957
Maj_StoUS
int value returned from unsigned char %s().
A value of type int is being returned from a function that is defined with type unsigned char.
{
int ret;
/* ... */
return(ret);
}

values.
3958
Maj_Small
int value returned from short %s().
A value of type int is being returned from a function that is defined with type short.
short foo ( void )
{
int ret;
/* ... */
return(ret);
}


3959
Maj_StoUS
int value returned from unsigned short %s().
A value of type int is being returned from a function that is defined with type unsigned short.
{
int ret;
/* ... */
return(ret);
}

values.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
145 of 181
A4 : 2003-02

3960
Maj_StoUS
int value returned from unsigned int %s().
A value of type int is being returned from a function that is defined with type unsigned int.
{
int ret;
/* ... */
return(ret);
}

values.
3962
Maj_StoUS
int value returned from unsigned long %s().
A value of type int is being returned from a function that is defined with type unsigned long.
{
int ret;
/* ... */
return(ret);
}

values.
3963
Maj_ItoFL
int value returned from float %s().
A value of type int is being returned from a function that is defined with type float.
float foo ( void )
{
int ret;
/* ... */
return(ret);
}

3964
Maj_ItoFL
int value returned from double %s().

A value of type int is being returned from a function that is defined with type double.
double foo ( void )
{
int ret;
/* ... */
return(ret);
}

3965
Maj_ItoFL
int value returned from long double %s().
A value of type int is being returned from a function that is defined with type long double.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
146 of 181
A4 : 2003-02

{
int ret;
/* ... */
return(ret);
}

3966
Maj_Pchar
unsigned int value returned from char %s().
A value of type unsigned int is being returned from a function that is defined with type char.
char foo ( void )
{
unsigned int ret;
/* ... */
return(ret);
}

3967
Maj_UStoS
unsigned int value returned from signed char %s().
A value of type unsigned int is being returned from a function that is defined with type signed char.
{
unsigned int ret;
/* ... */
return(ret);
}

3968
Maj_Small
unsigned int value returned from unsigned char %s().
A value of type unsigned int is being returned from a function that is defined with type unsigned char.


{
unsigned int ret;
/* ... */
return(ret);
}

3969
Maj_UStoS
unsigned int value returned from short %s().
A value of type unsigned int is being returned from a function that is defined with type short.
short foo ( void )
{
unsigned int ret;
/* ... */
return(ret);
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
147 of 181
A4 : 2003-02

}

3970
Maj_Small
unsigned int value returned from unsigned short %s().
A value of type unsigned int is being returned from a function that is defined with type unsigned short.
{
unsigned int ret;
/* ... */
return(ret);
}

3971
Maj_UStoS
unsigned int value returned from int %s().
A value of type unsigned int is being returned from a function that is defined with type int.
int foo ( void )
{
unsigned int ret;
/* ... */
return(ret);
}

3972
Maj_UStoLS
unsigned int value returned from long %s().

3974
Maj_ItoFL
unsigned int value returned from float %s().
A value of type unsigned int is being returned from a function that is defined with type float.

float foo ( void )

{
unsigned int ret;
/* ... */
return(ret);
}

3975
Maj_ItoFL
unsigned int value returned from double %s().
A value of type unsigned int is being returned from a function that is defined with type double.
double foo ( void )
{
unsigned int ret;
/* ... */
return(ret);
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
148 of 181
A4 : 2003-02

}

3976
Maj_ItoFL
unsigned int value returned from long double %s().
A value of type unsigned int is being returned from a function that is defined with type long double.
{
unsigned int ret;
/* ... */
return(ret);
}

3977
Maj_Pchar
long value returned from char %s().
A value of type long is being returned from a function that is defined with type char.
char foo ( void )
{
long ret;
/* ... */
return(ret);
}

3978
Maj_Small
long value returned from signed char %s().
A value of type long is being returned from a function that is defined with type signed char.
{
long ret;
/* ... */
return(ret);
}

3979
Maj_StoUS
long value returned from unsigned char %s().
A value of type long is being returned from a function that is defined with type unsigned char.
{
long ret;
/* ... */
return(ret);
}

values.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
149 of 181
A4 : 2003-02
3980
Maj_Small
long value returned from short %s().
A value of type long is being returned from a function that is defined with type short.
short foo ( void )
{
long ret;
/* ... */
return(ret);
}

3981
Maj_StoUS
long value returned from unsigned short %s().
A value of type long is being returned from a function that is defined with type unsigned short.
{
long ret;
/* ... */
return(ret);
}

A signed type is being converted to an unsigned type and so negative values will be converted
to large positive values.
3982
Maj_Small
long value returned from int %s().
A value of type long is being returned from a function that is defined with type int.
int foo ( void )
{
long ret;
/* ... */
return(ret);
}

3983
Maj_StoUS
long value returned from unsigned int %s().

A value of type long is being returned from a function that is defined with type unsigned int.
{
long ret;
/* ... */
return(ret);
}

values.
3984
Designed by
Maj_StoUS
long value returned from unsigned long %s().
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
150 of 181
A4 : 2003-02

A value of type long is being returned from a function that is defined with type unsigned long.
{
long ret;
/* ... */
return(ret);
}

values.
3985
Maj_ItoFL
long value returned from float %s().
A value of type long is being returned from a function that is defined with type float.
float foo ( void )
{
long ret;
/* ... */
return(ret);
}

3986
Maj_ItoFL
long value returned from double %s().
A value of type long is being returned from a function that is defined with type double.
double foo ( void )
{
long ret;
/* ... */
return(ret);
}
3987
Maj_ItoFL
long value returned from long double %s().
A value of type long is being returned from a function that is defined with type long double.

{
long ret;
/* ... */
return(ret);
}

3988
Maj_Pchar
unsigned long value returned from char %s().
A value of type unsigned long is being returned from a function that is defined with type char.
char foo ( void )
{
unsigned long ret;
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
151 of 181
A4 : 2003-02

/* ... */
return(ret);
}

3989
Maj_UStoS
unsigned long value returned from signed char %s().
A value of type unsigned long is being returned from a function that is defined with type signed char.
{
unsigned long ret;
/* ... */
return(ret);
}

3990
Maj_Small
unsigned long value returned from unsigned char %s().
A value of type unsigned long is being returned from a function that is defined with type unsigned char.
{
unsigned long ret;
/* ... */
return(ret);
}

3991
Maj_UStoS
unsigned long value returned from short %s().
A value of type unsigned long is being returned from a function that is defined with type short.
short foo ( void )
{
unsigned long ret;
/* ... */
return(ret);
}

3992
Maj_Small
unsigned long value returned from unsigned short %s().
A value of type unsigned long is being returned from a function that is defined with type unsigned short.
{
unsigned long ret;
/* ... */
return(ret);
}
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
152 of 181
A4 : 2003-02

3993
Maj_UStoS
unsigned long value returned from int %s().
A value of type unsigned long is being returned from a function that is defined with type int.
int foo ( void )
{
unsigned long ret;
/* ... */
return(ret);
}

3994
Maj_Small
unsigned long value returned from unsigned int %s().
A value of type unsigned long is being returned from a function that is defined with type unsigned int.
{
unsigned long ret;
/* ... */
return(ret);
}

3995
Maj_UStoS
unsigned long value returned from long %s().
A value of type unsigned long is being returned from a function that is defined with type long.
long foo ( void )
{
unsigned long ret;
/* ... */
return(ret);
}

3996
Maj_ItoFL
unsigned long value returned from float %s().

A value of type unsigned long is being returned from a function that is defined with type float.
float foo ( void )
{
unsigned long ret;
/* ... */
return(ret);
}

3997
Maj_ItoFL
unsigned long value returned from double %s().
A value of type unsigned long is being returned from a function that is defined with type double.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
153 of 181
A4 : 2003-02

double foo ( void )
{
unsigned long ret;
/* ... */
return(ret);
}

3998
Maj_ItoFL
unsigned long value returned from long double %s().
A value of type unsigned long is being returned from a function that is defined with type long double.
{
unsigned long ret;
/* ... */
return(ret);
}

3999
Maj_FLtoI
float value returned from char %s().
A value of type float is being returned from a function that is defined with type char.
char foo ( void )
{
float ret;
/* ... */
return(ret);
}

4000
Maj_FLtoI
float value returned from signed char %s().
A value of type float is being returned from a function that is defined with type signed char.
{
float ret;
/* ... */
return(ret);
}

4001
Maj_FLtoI
float value returned from unsigned char %s().
A value of type float is being returned from a function that is defined with type unsigned char.
{
float ret;
/* ... */
return(ret);
}
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
154 of 181
A4 : 2003-02

4002
Maj_FLtoI
float value returned from short %s().
A value of type float is being returned from a function that is defined with type short.
short foo ( void )
{
float ret;
/* ... */
return(ret);
}

4003
Maj_FLtoI
float value returned from unsigned short %s().
A value of type float is being returned from a function that is defined with type unsigned short.
{
float ret;
/* ... */
return(ret);
}

4004
Maj_FLtoI
float value returned from int %s().
A value of type float is being returned from a function that is defined with type int.
int foo ( void )
{
float ret;
/* ... */
return(ret);
}

4005
Maj_FLtoI
float value returned from unsigned int %s().

A value of type float is being returned from a function that is defined with type unsigned int.
{
float ret;
/* ... */
return(ret);
}
4006
Maj_FLtoI
float value returned from long %s().
A value of type float is being returned from a function that is defined with type long.
long foo ( void )
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
155 of 181
A4 : 2003-02

{
float ret;
/* ... */
return(ret);
}

4007
Maj_FLtoI
float value returned from unsigned long %s().
A value of type float is being returned from a function that is defined with type unsigned long.
{
float ret;
/* ... */
return(ret);
}

4010
Maj_FLtoI
double value returned from char %s().
A value of type double is being returned from a function that is defined with type char.
char foo ( void )
{
double ret;
/* ... */
return(ret);
}

4011
Maj_FLtoI
double value returned from signed char %s().
A value of type double is being returned from a function that is defined with type signed char.
{
double ret;
/* ... */
return(ret);
}

4012
Maj_FLtoI
double value returned from unsigned char %s().
A value of type double is being returned from a function that is defined with type unsigned char.
{
double ret;
/* ... */
return(ret);
}
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
156 of 181
A4 : 2003-02

4013
Maj_FLtoI
double value returned from short %s().
A value of type double is being returned from a function that is defined with type short.

short foo ( void )
{
double ret;
/* ... */
return(ret);
}

4014
Maj_FLtoI
double value returned from unsigned short %s().
A value of type double is being returned from a function that is defined with type unsigned short.
{
double ret;
/* ... */
return(ret);
}

4015
Maj_FLtoI
double value returned from int %s().
A value of type double is being returned from a function that is defined with type int.
int foo ( void )
{
double ret;
/* ... */
return(ret);
}

4016
Maj_FLtoI
double value returned from unsigned int %s().

A value of type double is being returned from a function that is defined with type unsigned int.
{
double ret;
/* ... */
return(ret);
}

4017
Maj_FLtoI
double value returned from long %s().
A value of type double is being returned from a function that is defined with type long.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
157 of 181
A4 : 2003-02

long foo ( void )
{
double ret;
/* ... */
return(ret);
}

4018
Maj_FLtoI
double value returned from unsigned long %s().
A value of type double is being returned from a function that is defined with type unsigned long.
{
double ret;
/* ... */
return(ret);
}

4019
Maj_Small
double value returned from float %s().
A value of type double is being returned from a function that is defined with type float.
float foo ( void )
{
double ret;
/* ... */
return(ret);
}

4021
Maj_FLtoI
long double value returned from char %s().
A value of type long double is being returned from a function that is defined with type char.

char foo ( void )

{
long double ret;
/* ... */
return(ret);
}

4022
Maj_FLtoI
long double value returned from signed char %s().
A value of type long double is being returned from a function that is defined with type signed char.
{
long double ret;
/* ... */
return(ret);
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
158 of 181
A4 : 2003-02

4023
Maj_FLtoI
long double value returned from unsigned char %s().
A value of type long double is being returned from a function that is defined with type unsigned char.
{
long double ret;
/* ... */
return(ret);
}

4024
Maj_FLtoI
long double value returned from short %s().
A value of type long double is being returned from a function that is defined with type short.
short foo ( void )
{
long double ret;
/* ... */
return(ret);
}

4025
Maj_FLtoI
long double value returned from unsigned short %s().
A value of type long double is being returned from a function that is defined with type unsigned short.
{
long double ret;
/* ... */
return(ret);
}

4026
Maj_FLtoI
long double value returned from int %s().

A value of type long double is being returned from a function that is defined with type int.
int foo ( void )
{
long double ret;
/* ... */
return(ret);
}

4027
Maj_FLtoI
long double value returned from unsigned int %s().
A value of type long double is being returned from a function that is defined with type unsigned int.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
159 of 181
A4 : 2003-02

{
long double ret;
/* ... */
return(ret);
}

4028
Maj_FLtoI
long double value returned from long %s().
A value of type long double is being returned from a function that is defined with type long.
long foo ( void )
{
long double ret;
/* ... */
return(ret);
}

4029
Maj_FLtoI
long double value returned from unsigned long %s().
A value of type long double is being returned from a function that is defined with type unsigned long.
{
long double ret;
/* ... */
return(ret);
}

4030
Maj_Small
long double value returned from float %s().
A value of type long double is being returned from a function that is defined with type float.

float foo ( void )

{
long double ret;
/* ... */
return(ret);
}

4031
Maj_Small
long double value returned from double %s().
A value of type long double is being returned from a function that is defined with type double.
double foo ( void )
{
long double ret;
/* ... */
return(ret);
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
160 of 181
A4 : 2003-02

}

4032
Maj_Pchar
char value returned from long long %s().

4033
Maj_Pchar
char value returned from unsigned long long %s().
An object of type char is being implicitly cast to an unsigned long long.

4034
Maj_UStoLS
unsigned char value returned from long long %s().

4037
Maj_StoUS
signed char value returned from unsigned long long %s().
4039
Maj_StoUS
short value returned from unsigned long long %s().

4040
Maj_UStoLS
unsigned short value returned from long long %s().

4043
Maj_StoUS
int value returned from unsigned long long %s().

4044
Maj_UStoLS
unsigned int value returned from long long %s().


4047
Maj_StoUS
long value returned from unsigned long long %s().
An object of type long is being implicitly cast to an unsigned long long.

4048
Maj_UStoLS
unsigned long value returned from long long %s().

4050
Maj_Pchar
long long value returned from char %s().
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
161 of 181
A4 : 2003-02

4051
Maj_Small long long value returned from signed char %s().

4052
Maj_StoUS
long long value returned from unsigned char %s().

4053
Maj_Small
long long value returned from short %s().

4054
Maj_StoUS
long long value returned from unsigned short %s().

4055
Maj_Small
long long value returned from int %s().

4056
Maj_StoUS
long long value returned from unsigned int %s().

4057
Maj_Small
long long value returned from long %s().

4058
Maj_StoUS
long long value returned from unsigned long %s().

4059
Maj_StoUS
long long value returned from unsigned long long %s().

4060
Maj_ItoFL
long long value returned from float %s().

4061
Maj_ItoFL
long long value returned from double %s().

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
162 of 181
A4 : 2003-02

4062
Maj_ItoFL
long long value returned from long double %s().

4063
Maj_Pchar
unsigned long long value returned from char %s().

4064
Maj_UStoS
unsigned long long value returned from signed char %s().
4065
Maj_Small
unsigned long long value returned from unsigned char %s().
4066
Maj_UStoS
unsigned long long value returned from short %s().

4067
Maj_Small
unsigned long long value returned from unsigned short %s().
An object of type unsigned long long is being implicitly cast to an unsigned short.
4068
Maj_UStoS
unsigned long long value returned from int %s().

4069
Maj_Small
unsigned long long value returned from unsigned int %s().
4070
Maj_UStoS
unsigned long long value returned from long %s().


4071
Maj_Small
unsigned long long value returned from unsigned long %s().
An object of type unsigned long long is being implicitly cast to an unsigned long.
4072
Maj_UStoS
unsigned long long value returned from long long %s().
4073
Maj_ItoFL
unsigned long long value returned from float %s().
An object of type unsigned long long is being implicitly cast to a float.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
163 of 181
A4 : 2003-02

4074
Maj_ItoFL
unsigned long long value returned from double %s().

4075
Maj_ItoFL
unsigned long long value returned from long double %s().
4076
Maj_FLtoI
float value returned from long long %s().

4077
Maj_FLtoI
float value returned from unsigned long long %s().
An object of type float is being implicitly cast to an unsigned long long.

4078
Maj_FLtoI
double value returned from long long %s().

4079
Maj_FLtoI
double value returned from unsigned long long %s().
An object of type double is being implicitly cast to an unsigned long long.

4080
Maj_FLtoI
long double value returned from long long %s().

4081
Maj_FLtoI
long double value returned from unsigned long long %s().
MISRA Rule 84: For functions with void return type, return statements shall not have an expression.
Example Code:

#include "misra.h"
extern void test_084(S32 i)
{
return( i + 1 );
}
QAC-Rule 0746
0746
Constraint
[C] 'return exp;' found in '%s()' whose result type is 'void'.
The ISO standard forbids the presence of a return statement (with a return expression) in a function whose return
type is 'void'. e.g.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
164 of 181
A4 : 2003-02

void func(void)
{
int i;
/* ... */
return i;
/* illegal */
}
3.2.14 Preprocessing Directives, Misra-Rules: 88, 89, 91, 94, 95, 96, 98, 99, 100
MISRA Rule 88: Non-standard characters shall not occur in header file names in #include directives.
QAC Messages 0815, 0816 have been taken out of this release, as they are more restrictive than MISRA
dictates. Example Code:
/* Permit nested C-style comments: */
#include "misra.h"
#include
#include
#include
#include
".\misra.h"
"John's.h"
"Fred's.h"
"Money$.h"
/*
/*
/*
/*
MISRA
MISRA
MISRA
MISRA
Violation
Violation
Violation
Violation
*/
*/
*/
*/
QAC-Rules 0813, 0814, 0831

0813
ISO_ExpU
[U] Using any of the characters ' " \\ or /* in '#include <%s>' gives undefined
behaviour.
The characters ',",\ and the string /* should not be used as part of the filename in a #include statement. This
means, for example, that the use of absolute path names in a PC environment is not supported. Avoid the use of
absolute paths. Compilers will accept them but it is better to separate path information from source code by using
the include path option to specify where files are located. For example:
#include <C:\project\header.h>
0814
ISO_ExpU
/* Message 813 */
[U] Using any of the characters ' \\ or /* in '#include "%s"' gives undefined
behaviour.

The characters ', \ and the string /* should not be used as part of the filename in a #include "..." statement. This
means, for example, that the use of absolute path names in a PC environment is not supported. Avoid the use of
absolute paths. Compilers will accept them but it is better to separate path information from source code by using
the include path option to specify where files are located. e.g.
#include "C:\project\header.h"
/* Message 814 */
0831
Lang_ext
[E] Use of '\\' in this '#include' line is a PC extension - '/' has been assumed.
This usage is non-portable.
Specifying paths for include files is considered bad practice as the code becomes non-portable. In a PC
environment the path separator character '\' presents particular problems because, in the C language, it is used
to introduce escape sequences in text strings. In this case the parser has identified a situation where PC paths
have been used i.e. '\'. If paths have to be specified , the use of Unix style '/' include paths would result in the
code being more portable.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
165 of 181
A4 : 2003-02

MISRA Rule 89: The #include directive shall be followed by either a <filename> or "filename" sequence.
The rule is interpreted to mean that the only other meaningful alternative form of a #include statement (use of a
macro to specify the filename) is not permitted. Example Code:
#define INC <misra.h>
#include misra.h
#include INC
#include "misra.h"

{
}
QAC-Rules: 0809, 0832

0809
ISO_ExpU
[U] The '#include' preprocessor directive should be followed by < h-charsequence> or "s-char-sequence".
The '#include' directive requires the specified filename be enclosed either within angle brackets <> (usually
denoting a system header) or within double quotes "" (usually denoting a user supplied header file). Whether a
filename is enclosed within <> or "" affects the locations an implementation may choose to search when
attempting to find the specified file. According to the ISO C standard not enclosing filenames within <> or ""
represents undefined behaviour. e.g.
#include glbdef.h
/* illegal - missing <> or "" */
fails because the filename 'glbdef.h' is not enclosed within either <> or "".
0832
Maj_Prepro
Macro substitution in #include preprocessor directive.
Specifying include names through a MACRO is not recommended by some programming standards. For
example:
#define TEST "foo.h"
/* macro substitution to create preprocessing #include directive */
#include TEST
MISRA Rule 91: Macros shall not be #define'd and #undef'd within a block.
Example Code:

#include "misra.h"
#define
#undef
L
L
5
/* MISRA Violation of Rule 92 - Advisory only */
extern S16 test_091(void)

{
#define M
10
/* MISRA Violation of Rule 91 - Required
#undef
M
/* MISRA Violation of Rule 91 - Required
and Rule 92 - Advisory
return(1);
}
*/
*/
QAC-Rule 0842
0842
Designed by
Min_Prepro
Macros shall not be #define'd and #undef'd within a block.
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
166 of 181
A4 : 2003-02

It is quite legal to place #define and #undef directives anywhere in source code because macros are not subject
to scoping rules like other identifiers. A macro definition is effective only following the point of definition in the
source code. However it can be considered good practice to use #define and #undef directives only at the top of
a source file (i.e. at file scope) to avoid any possible confusion. For example:
#define M1
void foo( void )
{
/* ... */
#undef M1
/* Message 842 */
/* ... */
}
MISRA Rule 94: A function-like macro shall not be 'called' without all of its arguments.
Example Code:
#include "misra.h"
#define
MAX(A,B)
(((A)>(B))?(A):(B))
extern S32 test_094( S32 i )

{
S32 k = 0;
k = MAX(i,1);
k = MAX(i);
return(k);
}
QAC-Rules: 0850, 0856

0850
ISO_ExpU
[U] Macro argument is empty.
The specified function-like macro invocation has not been supplied with an expected argument. The ISO standard
does not define the behaviour of conforming implementations when presented with a function-like macro which
has missing arguments.
#define STR(text) #text
...
void func(void)
{
char * msg = STR();
...
}
/* undefined */

is undefined because the use of STR() is missing the expected argument.

0856
Constraint
[C] Fewer arguments in macro call than specified in definition.
The macro call has been passed fewer arguments than were specified in the function-like macro definition.
#define MAX(a,b) ((a)>(b) ? (a) : (b))
...
long maxnum = MAX(intnum);
/* illegal */
is illegal because the MAX() macro was expecting two arguments but was only given one.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
167 of 181
A4 : 2003-02

MISRA Rule 95: Arguments to a function-like macro shall not contain tokens that look like pre-processing
directives.
Example Code:
#include "misra.h"
#define _ANSI_
#define STD(X) (X)
static const S32 stan = STD(
#ifdef _ANSI_
1
#else
2
#endif
);
/* MISRA Violation, illegal behaviour */
QAC-Rule 0853
0853
ISO_ExpU
[U] Macro arguments contain a sequence of tokens that has the form of a
preprocessing directive.
The ISO standard states that if there are sequences of preprocessing tokens within the list of arguments that
would otherwise act as preprocessing directives, the behaviour is undefined. Hence embedding preprocessor
directives as macro arguments may lead to portability problems. For example:
/* Using preprocessor directives in a macro */
#define PRE_PROC_ARGS(A) (A)
PRE_PROC_ARGS(
#ifdef 1
1
#else
12
#endif
)
MISRA Rule 96: In the definition of a function-like macro the whole definition, and each instance of a
parameter, shall be enclosed in parentheses.
Example Code:

#include "misra.h"
#define
#define
#define
#define
MAXCONST
MAX1(A,B)
MAX2(A,B)
RMAX(A,B)
5
((A)>(B))?(A):(B)
(A>B?A:B)
(((A)>(B))?(A):(B))
/*
/*
/*
/*
OK */
MISRA Violation */
MISRA Violation */
OK */
extern void test_096( S32 i, S32 j )

{
S32 k = MAXCONST;
k = MAX1(i,j);
k = RMAX(i,j);
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
168 of 181
A4 : 2003-02

}
QAC Rules: 3409, 3410

3409
Min_Prepro
Macro body not enclosed in ().
This message is only generated if the macro body contains operators and is not enclosed in ( ). If these operators
and the operands on which they operate are not enclosed within parentheses then use of the macro in certain
contexts could give rise to unexpected results. Parenthesising macro bodies prevents unexpected precedence
problems and improves reliability. For example:
#define ADD(a,b) a + b
/* ... */
x = 2 * ADD( 1, 2 );
/* ... */.
This statement expands to "x = 2 * 1 + 2" which gives rise to confusion over the intended precedence. The macro
definition would have been better written as:
#define ADD(a,b)
3410
((a) + (b))
Min_Prepro
Macro parameter not enclosed in ().
This message is specific to function-like macros and suggests that the macro parameters should be enclosed
within parentheses.
should read
#define SQUARE(a) ((a) * (a))
Enclosing the parameters within parentheses avoids the associated problems that can be produced when the
macro arguments are expressions themselves.
...
x = SQUARE(1 + 1)
The code fragment above assigns the value (1 + (1*1) + 1)=3 to 'x' instead of the perhaps expected ((1+1) *
(1+1))=4.
Parenthesising the parameters in the body of a macro definition avoids problems associated with operator
precedence.
MISRA Rule 98: There shall be at most one occurrence of the # or ## pre-processor operators in a single
macro definition.
Example Code:
#include "misra.h"
#define PASTE(front,middle,back) (#front##middle##back) /* MISRA Violation */

{
}
QAC-Rules: 0880, 0881

0880
ISO_ExpU
[U] Order of evaluation of # and ## operators is undefined.
The order in which the # and ## operators are evaluated by the preprocessor is unspecified by the C standard. It
is therefore not advisable to use both operators within the same macro. This message will be generated by a
statement such as:
#define debug(s) printf("x" # s"=%d\n", x ## s)
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
169 of 181
A4 : 2003-02
0881
ISO_ExpU
[U] Order of evaluation of multiple ## operators is undefined.
The order in which multiple ## operators are evaluated by the preprocessor is unspecified by the C standard. It is
therefore not advisable to use more than one ## operator within the same macro. This message will be generated
by a statement such as:
#define MACRO(A) (A##A=A##A)
MISRA Rule 99: All uses of the #pragma directive shall be documented and explained.
The QAC warning will identify the use of any #pragma directives that have not been specifically declared in the
QAC configuration. Example Code:
#include "misra.h"
#pragma push
/* MISRA Violation, unless configured in QAC */
#pragma pop
/* MISRA Violation, unless configured in QAC */
QAC-Rule 3116
3116
Min_Prepro
Unrecognised #pragma arguments '%s' This #pragma directive has been

ignored.
The argument to a '#pragma' is unrecognised. This is hardly surprising as '#pragma's are completely
implementation defined. No two implementations need support any or all of each others #pragmas.
If you don't have a good reason for using this directive then avoid it - it will only give you problems later.
MISRA Rule 100: The defined pre-processor operator shall only be used in one of the two standard forms.
Example Code:
#include "misra.h"
#define ID
#if !defined ID
#endif
#if defined
#endif
#if defined(ABCD)
#endif
#if defined( % )
#endif

{
}
QAC 0887, 0888

0887
ISO_ExpU
[U] Use of 'defined' must match either 'defined(identifier)' or 'defined identifier'.
The unary operator expression 'defined' expects an identifier argument where none was given.
...
#if defined()
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
170 of 181
A4 : 2003-02

...
0888
ISO_ExpU
[U] 'defined' requires an identifier as an argument.
'defined' requires an identifier as an argument. Not providing an identifier argument is a syntax error. For
example:
#if defined (%) /* Illegal use of 'defined' */
#endif
3.2.15 Pointers and Arrays, Misra-Rule: 106*
MISRA Rule 106: The address of an object with automatic storage shall not be assigned to an object
which may persist after the object has ceased to exist.
Example Code:
#include "misra.h"
extern S32 * test_106( S32 * * pi )
{
static S32 * pc;
S32 *p;
S32 c = 0;
{
S32 i = 1;
p = &i;
}
pc = &c;
*pi = &c;
return(&c);
QAC-Rules: 3216, 3217, 3225, 4140

3216
Maj_Ops
assigned to.

int main()
{
int *a;
{
int b;
a = &b;
}
}
3217
Maj_Ops

Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
171 of 181
A4 : 2003-02

void f(void)
{
static int* v;
int a;
}
3225
Maj_Ops
Function parameter returns address of a local non-static object.
void foo(int **appi)
{
int bi = 1;
...
*appi = &bi;
/* 3225 */
...
return;
}
4140
Maj_Ops
Function returns address of local data.
int *func ( int x )
{
int a=0;
/* ... */
return &a;
}
/* Message 4140 */
3.2.16 Structures and Unions, Misra-Rules: 108, 109, 110, 113

MISRA Rule 108: In the specification of a structure or union type, all members of the structure or union
shall be fully specified.
Example Code:
#include "misra.h"
extern struct Fred

extern union John
struct stag { };
fred;
john;
extern S32 test_108 (struct Rich rich)

{
struct Mike mike;
return 1;
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
172 of 181
A4 : 2003-02

QAC-Rules: 0554, 0545, 0623, 0636, 3310, 3313
0544
ISO_ExpU
[U] The value of an incomplete 'union' may not be used.
An incomplete union is a union declaration with no body part defined. Objects may be declared of incomplete union type but
the value of such an object cannot subsequently be used. For example:
void fn(void)
{
union John john; /* union John is incomplete */
int j = john;
/* hence john cannot have a value */
}
0545
ISO_ExpU
[U] The value of an incomplete 'struct' may not be used.
An incomplete struct is a struct declaration with no body part defined. Objects may be declared of incomplete
struct type but the value of such an object cannot subsequently be used. For example:
void fn(void)
{
extern struct John john;
int
j = john;
}
0623
ISO_ExpU
[U] '%s' has incomplete type and no linkage - this is undefined.
Identifiers declared to be function parameters, and block scope identifiers without an explicit 'extern' storageclass specifier all have no linkage. These identifiers must not be declared to be of an incomplete type.
Array types of unknown size, structure or union types of unknown content, and the type void are all incomplete
types.
This message is produced when an identifier with incomplete type occurs without linkage. For example:
{
struct record field;
/* ... */
}
In the above example there has been no definition of the 'record' structure so the declaration of 'field' is
incomplete. As the declaration appears in block scope it therefore has no linkage.
Maybe you are missing include files or you have misspelled the identifier.
0636
ISO_ExpU
[U] There are no named members in this 'struct' or 'union'.
A struct should consist of named members. e.g.

struct b
{
};
No members in this struct.

3310
Maj_array
No definition has yet been given for structure tag '%s'.
The identifier tag that you are using to declare this structure has not been defined. This is dangerous but not
illegal. It may have been defined in a header file that should be '#include'd in this file. For example:
static struct ST struct1; /* ST has not been defined - Message 3310 */
3313
Maj_array
No definition has been found for structure tag '%s'.
This structure tag has been used but has not been defined anywhere. Perhaps a header file should be included.
For example:
static struct ST struct1; /* ST not defined */
/* Message 3313 appears later */
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
173 of 181
A4 : 2003-02

MISRA Rule 109: Overlapping variable storage shall not be used.
The intent of this rule is that a common storage area should not be used to store unrelated data items required at
different times. However such practice is difficult to identify throuch static code analysis if objects are of the same
type. Sharing space for objects of different types can be accomplished by using unions and this is identified in
Rule 110. Example Code:
{
}
No QAC messages cover this rule

MISRA Rule 110: Unions shall not be used to access the sub-parts of larger data types.
This rule requires simply that unions shall not be used. Example Code:
#include "misra.h"
union test
{
S8 *c;
S32 i;
};
extern S32 test_110a( void )
{
union test mytest;
return(0);
}
extern void test_110b(union test *un)
{
un->i = 10;
}
QAC-Rules: 0750, 5110

0750
Min_Array
Unions shall not be used.
Unions shall not be used.

5110
MISRA_Rule_110_Req_ Unions shall not be used to access the sub-parts of larger data types.
MISRA Rule 113: All the members of a structure (or union) shall be named and shall only be accessed via
their name.
The ISO standard permits the declaration of unnamed bit-fields in order to facilitate padding. They can't be
accessed by normal methods.
MISRA stipulates that this feature should not be used. QAC will issue a warning if any bit-field is declared without
a name. Example Code:
#include "misra.h"
struct bitest
{
UBITFIELD b1: 3;
UBITFIELD b2: 11;
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
174 of 181
A4 : 2003-02

UBITFIELD
2;
};
QAC-Rules: 0660, 3663

0660
Min_Array
Unnamed structure/union member.
It is legitimate in ISO C to declare a structure member without an explicit name. Some find this useful when
defining unions; but it is not always considered good practice. For example:
struct sid
{
int a;
int b;
};
struct at
{
int n;
struct sid;
} atx;
/* Unnamed structure - Message 0660 */
A number of compilers allow the programmer to access the elements of the unnamed structure in the example
above using the constructs "atx.a" and "atx.b". However this is an extension to the ISO C language and should be
avoided in the interests of portability. QA C will recognise the construct and generate message 662.
3663
Min_Array
Declaring an unnamed bit-field.
Some programming standards prohibit the declaration of unnamed bit-fields. For example:
struct xbit
{
char a;
unsigned int : 1;
/* Message 3663 */
};
3.2.17 Standard Libraries, Misra-Rules: 114, 115, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127
MISRA Rule 114: Reserved words and standard library function names shall not be redefined or
undefined.
Example Code:
#include "misra.h"

#define defined !defined

#undef
#undef
#undef
#undef
#undef
#define
#define
#define
#define
#define
__LINE__
__FILE__
__DATE__
__TIME__
__STDC__
__LINE__
__FILE__
__DATE__
__TIME__
__STDC__
1
"default"
"01-01-2000"
"00:00:00"
/*
/*
/*
/*
/*
MISRA
MISRA
MISRA
MISRA
MISRA
Violation
Violation
Violation
Violation
Violation
*/
*/
*/
*/
*/
/*
/*
/*
/*
/*
MISRA
MISRA
MISRA
MISRA
MISRA
Violation
Violation
Violation
Violation
Violation
*/
*/
*/
*/
*/
S32 _anything = 1;
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
175 of 181
A4 : 2003-02

{
S32 strcpy = 0;
++_anything;
return(0);
}
QAC-Rules: 0836, 0848, 0854, 5114

0836
ISO_ExpU
[U] Definition of macro named 'defined'.
You have attempted to #define a macro called 'defined'. The word 'defined' is a preprocessor operator and it
should never be redefined or undefined. e.g.
#define defined "defined"
/* illegal */
'defined' is a reserved operator introduced to test for the presence of macro definitions.
It evaluates to 1 if its identifier operand is currently defined as a macro name and to 0 if it is not.
0848
ISO_ExpU
[U] Use of '#undef' to remove '%s' which is predefined by the compiler.
You have attempted to undefine one of the pre-defined macro names. e.g.
#undef __STDC__
/* illegal */
Pre-defined macro names which cannot be undefined include '__LINE__', '__FILE__', '__DATE__', '__TIME__'
and '__STDC__'.
In addition you cannot redefine these macro names using a '#define' directive.
Note that this message is not generated for attempts to undefine the `defined' macro - this generates message
837 instead.
0854
ISO_ExpU
[U] Redefinition of '%s', which is a predefined macro name.
You have attempted to '#define' one of the pre-defined macro names.

#define __DATE__ "Date:"
/* illegal */
Pre-defined macro names which cannot be redefined include '__LINE__', '__FILE__', '__DATE__', '__TIME__'
and '__STDC__'.
In addition you cannot undefine these macro names using a '#undef' directive.
5114 MISRA_Rule_114_Req_ Reserved words and standard library function names shall not be redefined or
undefined.
MISRA Rule 115: Standard library function names shall not be reused.
Identifiers prefixed with '_' are reserved for library use. Example Code:

#include "misra.h"
extern F32 sqrt( F32 d );
extern S8 printf[81];
{
F32 r = 2.0f;
r = sqrt( r );
printf[0] = 'A';
printf[1] = '\0';
return(0);
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
176 of 181
A4 : 2003-02

}
extern F32 sqrt( F32 d )
{
return( d );
}
QAC-Rules: 0602, 5115

0602
ISO_ExpU
int
main (void)
{
int __sigDefault;
/* warning 0602:
*/
int __sigIgnore;
/* prefix '__' reserved */
int __sigError;
/* for library use
*/
int _sigIgnore;
/* OK */
return 1;
}
5115
MISRA_Rule_115_Req_ Standard library function names shall not be reused.
MISRA Rule 118: Dynamic heap memory allocation shall not be used.
This rule is implemented through the use of the warncall feature of QAC. Any call to the functions malloc, calloc,
free, or realloc will be identified with message 5118.
Example Code:
#include <stdlib.h>
#include "misra.h"
#define L 4
{
S8 *p;

p = (S8 *) malloc(L);
free(p);
p = (S8 *) calloc(10,L);
p = (S8 *) realloc(p,L);
return(0);
}
QAC-rule: 5115
5118
MISRA_Rule_118_Req_ Dynamic heap memory allocation shall not be used.
MISRA Rule 119: The error indicator errno shall not be used.
Example Code:
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
177 of 181
A4 : 2003-02

#include <errno.h>
#include "misra.h"
{
S32 r = 0;
if ( errno != 0 )
{
r = 1;
}
/*
Misra violation
*/
return(r);
}
QAC-Rule: 5119
5119
MISRA_Rule_119_Req_ The error indicator errno shall not be used.
MISRA Rule 120: The macro offsetof, in library <stddef.h>, shall not be used.
Example Code:
#include <stddef.h>
#include "misra.h"
extern struct stag
{
S32 a;
F64 b;
} s;
{
size_t p;
s.a = 1;
s.b = 0.0;
p = offsetof(struct stag, b);

return(0);
QAC-Rule: 5120
5120
MISRA_Rule_120_Req_ The macro offsetof, in library <stddef.h>, shall not be used.
MISRA Rule 121: <locale.h> and the setlocale function shall not be used.
Use of setlocale is detected using the warncall feature in QAC. Example Code:
#include <locale.h>
#include "misra.h"
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
178 of 181
A4 : 2003-02

{
PC *pc;
pc = setlocale( LC_ALL, "" );
}
return(0);
QAC-Rule 5121
5121
MISRA_Rule_121_Req_ <locale.h> and the setlocale function shall not be used.
MISRA Rule 122: The setjmp macro and the longjmp function shall not be used.
Use of longjmp is detected using the warncall feature in QAC. setjmp is captured in post-processing.
Example Code:
#include
#include
<stddef.h>
<setjmp.h>
#include "misra.h"
{
S32
istat = 0;
jmp_buf myenv;
istat = setjmp ( myenv );
longjmp ( myenv, 9 );
}
return(0);
QAC-Rule 5122
5122
MISRA_Rule_122_Req_ The setjmp macro and the longjmp function shall not be used.
MISRA Rule 123: The signal handling facilities of <signal.h> shall not be used
Example Code:
#include <signal.h>
#include "misra.h"

{
S32 i = SIGINT;
return(i);
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
179 of 181
A4 : 2003-02

QAC-Rule: 5123
5123
MISRA_Rule_123_Req_ The signal handling facilities of <signal.h> shall not be used
MISRA Rule 124: The input/output library <stdio.h> shall not be used in production code.
Example Code:
#include <stdio.h>
#include "misra.h"

{
FILE
*fp;
fp = fopen( "test", "r" );
return(0);
}
QAC-Rule 5124
5124
MISRA_Rule_124_Req_ The input/output library <stdio.h> shall not be used in production code.
MISRA Rule 125: The library functions atof(), atoi() and atol() from library <stdlib.h> shall not be used.
Example Code:
#include <stdlib.h>
#include "misra.h"
extern S32 test_125( const PC *p )
{
F64 d = 0.0;
S32 l = 0;
d = atof( p );
l = atoi( p );
l = atol( p );
return(0);
}

QAC-Rule 5125
5125
MISRA_Rule_125_Req_ The library functions atof(), atoi() and atol() from library <stdlib.h> shall not be
used.
MISRA Rule 126: The library functions abort(), exit(), getenv() and system() from library <stdlib.h> shall
not be used.
Example Code:
#include <stdlib.h>
#include "misra.h"
S32 test_126( S32 arg )
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
180 of 181
A4 : 2003-02

{
S32
PC
i = 0;
*v;
if (arg < 3)
{
abort();
}
i = system( "test" );
if (arg == 4)
{
exit(1);
}
v = getenv( "test" );
return(0);
QAC-Rule 5126
5126
MISRA_Rule_126_Req_ The library functions abort(), exit(), getenv() and system() from library
<stdlib.h> shall not be used.
MISRA Rule 127: The time handling functions of library <time.h> shall not be used.
Use of the time.h functions is detected using the warncall feature in QAC. Example Code:
#include <stdlib.h>
#include <time.h>
#include "misra.h"
extern S32 test_127( time_t breakfast, time_t lunch )

{
F64
t;
t = difftime ( breakfast, lunch );
return (0);
}
QAC-Rule 5127
5127
3.3
MISRA_Rule_127_Req_ The time handling functions of library <time.h> shall not be used.
QAC-Set Metrics
QAC 4700
4700
Metrics
Metric value out of threshold range: %s.
There has been an infringement of a threshold on the specified metric.
Designed by
Date
Department
2003-03-12
SV I IP HVAC TA SW
Released by
Designation
Status
released
Documentkey
Pages
181 of 181
A4 : 2003-02

Hvac Programming Guide - Doc 0

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Hvac Programming Guide - Doc 0

Cargado por

Copyright:

Formatos disponibles

This document and the information ..............................................

Document, in so far as it is based on VDO authorship, are and remain

HVAC Programming Guideline

HVAC C-Programming Rules

Siemens VDO Automotive AG

Copyright ( C ) Siemens AG 2003

This document and the information ..............................................

HVAC Programming Guideline

Siemens VDO Automotive AG

Copyright ( C ) Siemens AG 2003

HVAC Programming Guideline

Basic-Set QAC 5.0.1......................................................................................................11

Rule g2.15 | Mandatory..........................................................................................11

QAC-Rules: 0468, 0469, 0808, 0810, 0838, 0839.........................................................11

Rule g2.28 | Mandatory..........................................................................................13

QAC-Rules: 0767, 0769, 3333.......................................................................................13

Rule mr2077 | Mandatory......................................................................................14

Rule mr2849 | Mandatory......................................................................................15

QAC-Rules: 0468, 0469.................................................................................................16

Rule mr2850 | Mandatory......................................................................................16

Rule r2.01 | Mandatory...........................................................................................17

QAC-Rules: 0346, 0602, 0836, 1300, 1301, 3602, 3615?............................................18

Rule r2.05 | Mandatory...........................................................................................19

QAC-Rules: 0543, 0744, 0745, 0746.............................................................................19

Rule r2.06 | Mandatory...........................................................................................20

QAC-Rules: 0304, 0454, 0775, 2711, 3620...................................................................20

This document and the information ..............................................

Rule r2.13 | Mandatory...........................................................................................21

Rule r2.39 | Mandatory...........................................................................................63

Copyright ( C ) Siemens AG 2003

HVAC Programming Guideline

Rule r2.40 | Mandatory...........................................................................................68

QAC-Rules: 3216, 3217, 3225, 3348, 3349, 4140........................................................69

Rule r2.51 | Mandatory...........................................................................................71

QAC-Rules: 3409, 3410, 3411, 3430.............................................................................71

Rule r2.53 | Mandatory...........................................................................................72

Rule r2-56 | Mandatory..........................................................................................74

QAC-Rules: 1300, 1301.................................................................................................74

Rule r4.11 | Recommended...................................................................................75

Rule r4.2 | Mandatory.............................................................................................75

Rule SMK502 | Mandatory.....................................................................................81

This document and the information ..............................................

MISRA Rule 9: Comments shall not be nested..........................................................92

Copyright ( C ) Siemens AG 2003

HVAC Programming Guideline

This document and the information ..............................................

Operators, Misra Rules: 33*, 34, 35, 36, 37*, 42................................................102

Copyright ( C ) Siemens AG 2003

HVAC Programming Guideline

Expressions, Misra-Rules 46, 49, 50..................................................................111

This document and the information ..............................................

MISRA Rule 53: All non-null statements shall have a side-effect..........................115

Copyright ( C ) Siemens AG 2003

HVAC Programming Guideline

MISRA Rule 68: Functions shall always be declared at file scope........................124

This document and the information ..............................................

QAC-Rules 1331, 1332, 1333......................................................................................127

Copyright ( C ) Siemens AG 2003

HVAC Programming Guideline

QAC-Rules: 0809, 0832...............................................................................................164

Copyright ( C ) Siemens AG 2003

HVAC Programming Guideline

Pointers and Arrays, Misra-Rule: 106*...............................................................169

Operators, Misra Rules: 33, 34, 35, 36, 37, 42................................................102