<![CDATA[MISRA Discussion Forums - 6.8 Declarations and Definitions]]>

<![CDATA[MISRA Discussion Forums - 6.8 Declarations and Definitions]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 19:06:27 +0000 MyBB <![CDATA[Rule 8.3 Function definition]]> https://forum.misra.org.uk/showthread.php?tid=1401 Wed, 21 Feb 2018 10:12:20 +0000 ankitshah413]]> https://forum.misra.org.uk/showthread.php?tid=1401

Code:
(void)Dem_SetEventStatus((Dem_EventIdType)(dtcFlt_t.dtc[dtcIndex]), DEM_EVENT_STATUS_FAILED);

Here Dem_SetEventStatus is defined in one header as under:

Code:
extern FUNC(Std_ReturnType, RTE_CODE) Dem_SetEventStatus (Dem_ASR42_EventIdType EventId, Dem_ASR42_EventStatusType EventStatus);

Here Dem_EventIdType is a typedef of unit8 and Dem_ASR42_EventIdType is unsigned short.

So , there were the violation of MISRA 8.3 right??]]>

Code:
(void)Dem_SetEventStatus((Dem_EventIdType)(dtcFlt_t.dtc[dtcIndex]), DEM_EVENT_STATUS_FAILED);

Here Dem_SetEventStatus is defined in one header as under:

Code:
extern FUNC(Std_ReturnType, RTE_CODE) Dem_SetEventStatus (Dem_ASR42_EventIdType EventId, Dem_ASR42_EventStatusType EventStatus);

Here Dem_EventIdType is a typedef of unit8 and Dem_ASR42_EventIdType is unsigned short.

So , there were the violation of MISRA 8.3 right??]]> <![CDATA[Rule 8.3: Symbol redeclared]]> https://forum.misra.org.uk/showthread.php?tid=1399 Fri, 16 Feb 2018 12:34:55 +0000 ankitshah413]]> https://forum.misra.org.uk/showthread.php?tid=1399
I am facing an issue relating to rule 8.3. I am fixing MISRA violations in the project. The following code line is where i have issue:

in one of the files in the project i have the following code line:

dies->DrvPosn_D_SvRc_Rq = get_DrvPosn_D_SvRc_Rq();

get_DrvPosn_D_SvRc_Rq() is defined in other file as below:

tm_uint8 get_DrvPosn_D_SvRc_Rq(void)
{
return cio_DrvPosn_D_SvRc_Rq;
}

When i am performing the MISRA check , i get a error at 'dies->DrvPosn_D_SvRc_Rq = get_DrvPosn_D_SvRc_Rq();' line saying that Symbol 'get_DrvPosn_D_SvRc_Rq(void)' redeclared .

All the variables have same datatype tm_uint8;

Can you point out where the issue lies?

Thank you!

Ankit]]>
I am facing an issue relating to rule 8.3. I am fixing MISRA violations in the project. The following code line is where i have issue:

in one of the files in the project i have the following code line:

dies->DrvPosn_D_SvRc_Rq = get_DrvPosn_D_SvRc_Rq();

get_DrvPosn_D_SvRc_Rq() is defined in other file as below:

tm_uint8 get_DrvPosn_D_SvRc_Rq(void)
{
return cio_DrvPosn_D_SvRc_Rq;
}

When i am performing the MISRA check , i get a error at 'dies->DrvPosn_D_SvRc_Rq = get_DrvPosn_D_SvRc_Rq();' line saying that Symbol 'get_DrvPosn_D_SvRc_Rq(void)' redeclared .

All the variables have same datatype tm_uint8;

Can you point out where the issue lies?

Thank you!

Ankit]]> <![CDATA[Rule 8.5 - #define with function code in header files]]> https://forum.misra.org.uk/showthread.php?tid=1199 Tue, 18 Aug 2015 14:47:16 +0000 reito]]> https://forum.misra.org.uk/showthread.php?tid=1199 I would like to confirm the following interpretation of the rule 8.5. The rule says that "Header files should be used to declare objects, functions, typedefs, and macros. Header files shall not contain or produce definitions of objects or functions (or fragment of functions or objects) that occupy storage."

I have seen a couple of alerts in code raised when the header file contains a macro that generates the "body of one function". My understanding is that this is the case where the "macro produces definitions of objects or functions", and that this is a violation to be corrected.

In a similar way, if the header file contains a #typedef for an struct, should it be considered a violation to this rule?

Thanks in advance.]]> I would like to confirm the following interpretation of the rule 8.5. The rule says that "Header files should be used to declare objects, functions, typedefs, and macros. Header files shall not contain or produce definitions of objects or functions (or fragment of functions or objects) that occupy storage."

I have seen a couple of alerts in code raised when the header file contains a macro that generates the "body of one function". My understanding is that this is the case where the "macro produces definitions of objects or functions", and that this is a violation to be corrected.

In a similar way, if the header file contains a #typedef for an struct, should it be considered a violation to this rule?

Thanks in advance.]]> <![CDATA[MISRA 8.5 with inline function]]> https://forum.misra.org.uk/showthread.php?tid=1056 Thu, 15 May 2014 13:51:25 +0000 ziomocci]]> https://forum.misra.org.uk/showthread.php?tid=1056
I have an header file with inline function, like:

Code:
inline void DIGIO_InOut(uint8_T type, uint16_T pid)

{

    /* Do something */

}

and, without MISRA 8.5 activated, I am able to use/export methods without problems.

Well, activating the rules, of course I can not keep body of inline function inside header file (just for info, I am using ghs compiler).
Is it possible to put declaration of inline function in and declaration in , like:

Code:
inline void DIGIO_InOut(uint8_T type, uint16_T pid);

inline void DIGIO_InOut(uint8_T type, uint16_T pid)

{

    /* Do something */

}

?

Thank you in advance,

Best regards,

Andrea Mocci, Embedded SW developer at Akhela s.r.l.]]>
I have an header file with inline function, like:

Code:
inline void DIGIO_InOut(uint8_T type, uint16_T pid)

{

    /* Do something */

}

Code:
inline void DIGIO_InOut(uint8_T type, uint16_T pid);

inline void DIGIO_InOut(uint8_T type, uint16_T pid)

{

    /* Do something */

}

?

Thank you in advance,

Best regards,

Andrea Mocci, Embedded SW developer at Akhela s.r.l.]]> <![CDATA[MISRA 8.1]]> https://forum.misra.org.uk/showthread.php?tid=957 Wed, 10 Apr 2013 09:17:25 +0000 spd123]]> https://forum.misra.org.uk/showthread.php?tid=957
[ MISRA 8.1 ] Functions shall have prototype and prototype shall be visible at both the definition and call

I am using cystal revs for C MISRA C 2004 compliance.
Its showing violation in following code. pl. suggest solution for this.

controller specific header file
-----------------------------------------
SFR( P0, 0x80U ); /* Port 0 Latch */

Main.c
----------
void main( void )
Global_Frame[ 0 ] = ( U8 )( Mid_No & 0x1fU ); /* bit of mid */]]>
[ MISRA 8.1 ] Functions shall have prototype and prototype shall be visible at both the definition and call

I am using cystal revs for C MISRA C 2004 compliance.
Its showing violation in following code. pl. suggest solution for this.

controller specific header file
-----------------------------------------
SFR( P0, 0x80U ); /* Port 0 Latch */

Main.c
----------
void main( void )
Global_Frame[ 0 ] = ( U8 )( Mid_No & 0x1fU ); /* bit of mid */]]> <![CDATA[8.7 and design for testatbility]]> https://forum.misra.org.uk/showthread.php?tid=937 Thu, 24 Jan 2013 15:08:56 +0000 ggentile]]> https://forum.misra.org.uk/showthread.php?tid=937 Infact when you have a static variabile defined at block level, right now you have no way to perform any white box testing withot changing/adding code to copy the value to a global variable.

Let me know

Giacomo]]> Infact when you have a static variabile defined at block level, right now you have no way to perform any white box testing withot changing/adding code to copy the value to a global variable.

Let me know

Giacomo]]> <![CDATA[8.9 and 3rd party library code]]> https://forum.misra.org.uk/showthread.php?tid=889 Mon, 19 Mar 2012 15:32:35 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=889 Does rule #8.9 apply to objects/functions declared in 3rd party library code?

Thanks]]> Does rule #8.9 apply to objects/functions declared in 3rd party library code?

Thanks]]> <![CDATA[Does this code violate rule #8.7?]]> https://forum.misra.org.uk/showthread.php?tid=882 Wed, 15 Feb 2012 19:30:50 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=882

Code:
file1.c:

        static int i;

        int j[1] = { i };

file2.c:

        extern int j[1];

        void f()

            {

            int k = j[0];

            }

Does this code violate rule #8.7, "Objects shall be defined at block scope if they are only accessed from within a single function"?]]>

Code:
file1.c:

        static int i;

        int j[1] = { i };

file2.c:

        extern int j[1];

        void f()

            {

            int k = j[0];

            }

Does this code violate rule #8.7, "Objects shall be defined at block scope if they are only accessed from within a single function"?]]> <![CDATA[Rule #8.7 for "special function registers" and others?]]> https://forum.misra.org.uk/showthread.php?tid=831 Wed, 15 Jun 2011 19:39:07 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=831 <![CDATA[Meaning of rule 8.4 for function prototypes]]> https://forum.misra.org.uk/showthread.php?tid=820 Wed, 30 Mar 2011 08:02:34 +0000 dcrocker]]> https://forum.misra.org.uk/showthread.php?tid=820
File1.h:
typedef short int int16_t;

File2.h:
short int foo(short int a);

File3.h:
int16_t foo(int16_t a);

Does this break any MISRA rules? I ask because rule 8.3 states that for a function, the types in the prototype must match the types in the definition *exactly*. However, rule 8.4 states that when an object *or function* is declared more than once, the types in the declarations must be compatible, which is a weaker requirement. Why were the words "or function" included in rule 8.4?

My intepretation is that if my source code includes a definition of function foo, then I must be violating rules 8.3 (because at most one of the prototypes can have types that exactly match the types in the definition); but it my code doesn't include a definition for foo (e.g. because it is in a compiler-supplied library), I am free to provide two or more prototypes for it with non-identical but compatible types.]]>
File1.h:
typedef short int int16_t;

File2.h:
short int foo(short int a);

File3.h:
int16_t foo(int16_t a);

Does this break any MISRA rules? I ask because rule 8.3 states that for a function, the types in the prototype must match the types in the definition *exactly*. However, rule 8.4 states that when an object *or function* is declared more than once, the types in the declarations must be compatible, which is a weaker requirement. Why were the words "or function" included in rule 8.4?

My intepretation is that if my source code includes a definition of function foo, then I must be violating rules 8.3 (because at most one of the prototypes can have types that exactly match the types in the definition); but it my code doesn't include a definition for foo (e.g. because it is in a compiler-supplied library), I am free to provide two or more prototypes for it with non-identical but compatible types.]]> <![CDATA[Rule 8.10 Register Mapping]]> https://forum.misra.org.uk/showthread.php?tid=728 Wed, 31 Mar 2010 07:52:05 +0000 mshearer123]]> https://forum.misra.org.uk/showthread.php?tid=728 I am using IBM logiscope to bring a pic24 project to MISRA compliance.

Due to the use of unions in the standard PIC header file (which maps all the registers to the locations in the linker) I have created my own local register mappings whenever needed.

i.e. for PORT configuration source, the header contains

Code:
extern volatile unsigned int  TRISA;

typedef struct 

{

  unsigned TRISA0:1;

  unsigned TRISA1:1;

  unsigned TRISA2:1;

  unsigned TRISA3:1;

  unsigned TRISA4:1;

  unsigned :2;

  unsigned TRISA7:1;

  unsigned TRISA8:1;

  unsigned TRISA9:1;

  unsigned TRISA10:1;

} TRISABITS;

extern volatile TRISABITS TRISAbits;

extern volatile unsigned int TRISB;

typedef struct

 {

  unsigned TRISB0:1;

  unsigned TRISB1:1;

  unsigned TRISB2:1;

  unsigned TRISB3:1;

  unsigned TRISB4:1;

  unsigned TRISB5:1;

  unsigned TRISB6:1;

  unsigned TRISB7:1;

  unsigned TRISB8:1;

  unsigned TRISB9:1;

  unsigned TRISB10:1;

  unsigned TRISB11:1;

  unsigned TRISB12:1;

  unsigned TRISB13:1;

  unsigned TRISB14:1;

  unsigned TRISB15:1;

} TRISBBITS;

extern volatile TRISBBITS TRISBbits;

extern volatile unsigned int  TRISC;

typedef struct

{

  unsigned TRISC0:1;

  unsigned TRISC1:1;

  unsigned TRISC2:1;

  unsigned TRISC3:1;

  unsigned TRISC4:1;

  unsigned TRISC5:1;

  unsigned TRISC6:1;

  unsigned TRISC7:1;

  unsigned TRISC8:1;

  unsigned TRISC9:1;

} TRISCBITS;

extern volatile TRISCBITS TRISCbits;

extern volatile unsigned int  LATA;

typedef struct

{

  unsigned LATA0:1;

  unsigned LATA1:1;

  unsigned LATA2:1;

  unsigned LATA3:1;

  unsigned LATA4:1;

  unsigned :2;

  unsigned LATA7:1;

  unsigned LATA8:1;

  unsigned LATA9:1;

  unsigned LATA10:1;

} LATABITS;

extern volatile LATABITS LATAbits;

The problem is, I don't have the linker file contained in my project, so therefore logiscope misses it and suggests all the extern variables should be static.
How can get around this?

Matthew Shearer]]> I am using IBM logiscope to bring a pic24 project to MISRA compliance.

Due to the use of unions in the standard PIC header file (which maps all the registers to the locations in the linker) I have created my own local register mappings whenever needed.

i.e. for PORT configuration source, the header contains

Code:
extern volatile unsigned int  TRISA;

typedef struct 

{

  unsigned TRISA0:1;

  unsigned TRISA1:1;

  unsigned TRISA2:1;

  unsigned TRISA3:1;

  unsigned TRISA4:1;

  unsigned :2;

  unsigned TRISA7:1;

  unsigned TRISA8:1;

  unsigned TRISA9:1;

  unsigned TRISA10:1;

} TRISABITS;

extern volatile TRISABITS TRISAbits;

extern volatile unsigned int TRISB;

typedef struct

 {

  unsigned TRISB0:1;

  unsigned TRISB1:1;

  unsigned TRISB2:1;

  unsigned TRISB3:1;

  unsigned TRISB4:1;

  unsigned TRISB5:1;

  unsigned TRISB6:1;

  unsigned TRISB7:1;

  unsigned TRISB8:1;

  unsigned TRISB9:1;

  unsigned TRISB10:1;

  unsigned TRISB11:1;

  unsigned TRISB12:1;

  unsigned TRISB13:1;

  unsigned TRISB14:1;

  unsigned TRISB15:1;

} TRISBBITS;

extern volatile TRISBBITS TRISBbits;

extern volatile unsigned int  TRISC;

typedef struct

{

  unsigned TRISC0:1;

  unsigned TRISC1:1;

  unsigned TRISC2:1;

  unsigned TRISC3:1;

  unsigned TRISC4:1;

  unsigned TRISC5:1;

  unsigned TRISC6:1;

  unsigned TRISC7:1;

  unsigned TRISC8:1;

  unsigned TRISC9:1;

} TRISCBITS;

extern volatile TRISCBITS TRISCbits;

extern volatile unsigned int  LATA;

typedef struct

{

  unsigned LATA0:1;

  unsigned LATA1:1;

  unsigned LATA2:1;

  unsigned LATA3:1;

  unsigned LATA4:1;

  unsigned :2;

  unsigned LATA7:1;

  unsigned LATA8:1;

  unsigned LATA9:1;

  unsigned LATA10:1;

} LATABITS;

extern volatile LATABITS LATAbits;

The problem is, I don't have the linker file contained in my project, so therefore logiscope misses it and suggests all the extern variables should be static.
How can get around this?

Matthew Shearer]]> <![CDATA[8.7 if applied to C++]]> https://forum.misra.org.uk/showthread.php?tid=716 Mon, 15 Mar 2010 18:25:09 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=716 <![CDATA[8.7 wording?]]> https://forum.misra.org.uk/showthread.php?tid=709 Thu, 25 Feb 2010 19:47:20 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=709 declared instead of defined?]]> declared instead of defined?]]> <![CDATA[Rule 8.1 and static functions]]> https://forum.misra.org.uk/showthread.php?tid=657 Fri, 22 May 2009 12:47:13 +0000 Renishug]]> https://forum.misra.org.uk/showthread.php?tid=657
My question concerns a subset situation of this rule: why should functions marked static have prototype declarations visible at the function definition?

Here is an example of the scenario, all in the same .c file:

static int8_t my_function( void );

...

float64_t my_other_function( void )
{
...
my_int8_var = my_function();
...
}

static int8_t my_function( void )
{
...
}

Elsewhere in the file there my be other calls of my_function too. This file conforms to rule 8.1. If I re-arrange the textual order of the file to make sure that the definition of my_function occurs before any calls of it, then the prototype effectively becomes redundant:

static int8_t my_function( void );

static int8_t my_function( void )
{
...
}

...

float64_t my_other_function( void )
{
...
my_int8_var = my_function();
...
}

Realistically, the prototype for my_function, usually placed towards the top of the .c file, is done by copy and paste from the function definition, with a semicolon added to the end of it. To me, as long as the textual order is right, the prototype just becomes something with no value to maintain, e.g. if you were to alter the function signature you would have to do so in two places rather than just one.

I have tried to work out why MISRA would want the rule as it is, inclusive of static functions. (I'm ok with the rule otherwise.) I reckon that it might be for this reason: the prototype for static functions are there for the day when someone does some maintenance on the .c file and adds a call to a static function textually before the definition of the function. With a prototype there, the call would be checked for consistency; without a prototype there, if the maintainer forgets to alter the textual order of the function definitions, the function call is unchecked and so has a risk of being in error.

Have I answered my own question?]]>
My question concerns a subset situation of this rule: why should functions marked static have prototype declarations visible at the function definition?

Here is an example of the scenario, all in the same .c file:

static int8_t my_function( void );

...

float64_t my_other_function( void )
{
...
my_int8_var = my_function();
...
}

static int8_t my_function( void )
{
...
}

Elsewhere in the file there my be other calls of my_function too. This file conforms to rule 8.1. If I re-arrange the textual order of the file to make sure that the definition of my_function occurs before any calls of it, then the prototype effectively becomes redundant:

static int8_t my_function( void );

static int8_t my_function( void )
{
...
}

...

float64_t my_other_function( void )
{
...
my_int8_var = my_function();
...
}

Realistically, the prototype for my_function, usually placed towards the top of the .c file, is done by copy and paste from the function definition, with a semicolon added to the end of it. To me, as long as the textual order is right, the prototype just becomes something with no value to maintain, e.g. if you were to alter the function signature you would have to do so in two places rather than just one.

I have tried to work out why MISRA would want the rule as it is, inclusive of static functions. (I'm ok with the rule otherwise.) I reckon that it might be for this reason: the prototype for static functions are there for the day when someone does some maintenance on the .c file and adds a call to a static function textually before the definition of the function. With a prototype there, the call would be checked for consistency; without a prototype there, if the maintainer forgets to alter the textual order of the function definitions, the function call is unchecked and so has a risk of being in error.

Have I answered my own question?]]> <![CDATA[Rule 8.10 and init functions]]> https://forum.misra.org.uk/showthread.php?tid=598 Fri, 28 Nov 2008 09:41:56 +0000 Christoph]]> https://forum.misra.org.uk/showthread.php?tid=598
usualy when a C module is designed (at our company), it consists of at least one external function. An example:

module.h:
extern void initModule()
extern void setData(uint8_t data)
extern uint8_t getData()

now initModule() is called in main (once in the whole software), as it is an init function. From a design point of
view module.* is the right place for initModule(), but Misra suggests to define it in main, since it is only called there.
I think this is bad design and not always possible (e.g. because module variables are hidden and not accessible form main).

So what is your recommendation in such a case? Is there a best practice for this pattern?

Best Regards
Christoph]]>
usualy when a C module is designed (at our company), it consists of at least one external function. An example:

module.h:
extern void initModule()
extern void setData(uint8_t data)
extern uint8_t getData()

now initModule() is called in main (once in the whole software), as it is an init function. From a design point of
view module.* is the right place for initModule(), but Misra suggests to define it in main, since it is only called there.
I think this is bad design and not always possible (e.g. because module variables are hidden and not accessible form main).

So what is your recommendation in such a case? Is there a best practice for this pattern?

Best Regards
Christoph]]>