<![CDATA[MISRA Discussion Forums - 8.8 Declarations and defnitions]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 13:03:38 +0000 MyBB <![CDATA[It 8.12 intended to be so strict?]]> https://forum.misra.org.uk/showthread.php?tid=1774 Thu, 25 Jun 2026 22:05:26 +0000 Loïc]]> https://forum.misra.org.uk/showthread.php?tid=1774
It is clear by looking at the title of rule 8.12 
Quote:Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique

That the following code is non-compliant:

Code:
// Non-compliant, yellow has an implixitly defined value that it shares with last
enum colour { red, blue, green, yellow, last = yellow };

This is a relatively common pattern, and the alternatives seem worse.

It is the intent of this rule to prevent this pattern, or is it just a result of the wording?
By the way, this code is compliant with the C++ version of this rule in MISRA C++:2023.]]>
It is clear by looking at the title of rule 8.12 
Quote:Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique

That the following code is non-compliant:

Code:
// Non-compliant, yellow has an implixitly defined value that it shares with last
enum colour { red, blue, green, yellow, last = yellow };

This is a relatively common pattern, and the alternatives seem worse.

It is the intent of this rule to prevent this pattern, or is it just a result of the wording?
By the way, this code is compliant with the C++ version of this rule in MISRA C++:2023.]]> <![CDATA[8.2 Function types shall be in prototype form with named parameters]]> https://forum.misra.org.uk/showthread.php?tid=1634 Tue, 27 Sep 2022 12:02:52 +0000 sowisojh]]> https://forum.misra.org.uk/showthread.php?tid=1634
Code:
myheader.h

/* define a type of a callback function */
typedef uint16_t(my_callback_fct_t)(uint16_t const *a);


myimplementation.c

#include "myheader.h"

/* function declaration of myCallbackFunction */
static my_callback_fct_t myCallbackFunction;

[...]

/* function definition of myCallbackFunction */
static uint16_t myCallbackFunction(uint16_t const *a)
{
  return (*a) + (uint16_t)1u;
}

Does the function declaration of myCallbackFunction in the above code comply with the Rule 8.2?
As the prototype specifies the parameters by usage of the type my_callback_fct_t and this prototype includes all the parameter and their names I would treat this as a correct prototype as requested by Rule 8.2. even though this is not explicitly listed as being compliant in the MISRA standard.

The background for this kind of function prototyping is to tie the function to an externally defined function prototype which will be used for callbacks in another part of the code.

kind regards
sowiso]]>
Code:
myheader.h

/* define a type of a callback function */
typedef uint16_t(my_callback_fct_t)(uint16_t const *a);


myimplementation.c

#include "myheader.h"

/* function declaration of myCallbackFunction */
static my_callback_fct_t myCallbackFunction;

[...]

/* function definition of myCallbackFunction */
static uint16_t myCallbackFunction(uint16_t const *a)
{
  return (*a) + (uint16_t)1u;
}

Does the function declaration of myCallbackFunction in the above code comply with the Rule 8.2?
As the prototype specifies the parameters by usage of the type my_callback_fct_t and this prototype includes all the parameter and their names I would treat this as a correct prototype as requested by Rule 8.2. even though this is not explicitly listed as being compliant in the MISRA standard.

The background for this kind of function prototyping is to tie the function to an externally defined function prototype which will be used for callbacks in another part of the code.

kind regards
sowiso]]> <![CDATA[Rule 8.7: clarifications of no linkage for an object]]> https://forum.misra.org.uk/showthread.php?tid=1618 Thu, 28 Apr 2022 06:18:24 +0000 chenzhuowansui]]> https://forum.misra.org.uk/showthread.php?tid=1618
could anyone help explain the following sentence in the Rationale part of Rule 8.7



Quote:Restricting the visibility of an object by giving it internal linkage or no linkage reduces the chance that
it might be accessed inadvertently.


as specified by the C standard:



Quote: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. If
the declaration of an identifier for an object has file scope and no storage-class specifier,
its linkage is external.


if an object is declared with no linkage, the default linkage is external linkage, so why giving no linkage to an object could restrict the visibility and reduces the chance that it might be accessed inadvertently?

thanks!]]>
could anyone help explain the following sentence in the Rationale part of Rule 8.7



Quote:Restricting the visibility of an object by giving it internal linkage or no linkage reduces the chance that
it might be accessed inadvertently.


as specified by the C standard:



Quote: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. If
the declaration of an identifier for an object has file scope and no storage-class specifier,
its linkage is external.


if an object is declared with no linkage, the default linkage is external linkage, so why giving no linkage to an object could restrict the visibility and reduces the chance that it might be accessed inadvertently?

thanks!]]> <![CDATA[Rule8.9 applicability to const ?]]> https://forum.misra.org.uk/showthread.php?tid=1580 Fri, 24 Sep 2021 13:49:38 +0000 Soren_Kolbach_Hansen]]> https://forum.misra.org.uk/showthread.php?tid=1580
I have a question regarding rule 8.9.

We are currenly using static const instead of defines at the top of our files to manage implementation specific constants, however this is being flagged as a violation of rule8.9 if only used in one function, however as per the rationale of 8.9 this does not make all that much sense to us, is this really the intent of the rule?

Best regards

Soren]]>
I have a question regarding rule 8.9.

We are currenly using static const instead of defines at the top of our files to manage implementation specific constants, however this is being flagged as a violation of rule8.9 if only used in one function, however as per the rationale of 8.9 this does not make all that much sense to us, is this really the intent of the rule?

Best regards

Soren]]> <![CDATA[Definition of "object"]]> https://forum.misra.org.uk/showthread.php?tid=1486 Wed, 17 Apr 2019 00:21:58 +0000 mz99]]> https://forum.misra.org.uk/showthread.php?tid=1486 What is the definition of "object" in MISRA-C:2012?
Which of the following are considered as "object" in MISRA-C:2012?
  • Variable
  • Const-qualified variable
  • Function
  • Object-like macro
  • Function-like macro
]]> What is the definition of "object" in MISRA-C:2012?
Which of the following are considered as "object" in MISRA-C:2012?
  • Variable
  • Const-qualified variable
  • Function
  • Object-like macro
  • Function-like macro
]]> <![CDATA[Rule 8.7 clarification needed]]> https://forum.misra.org.uk/showthread.php?tid=1459 Wed, 28 Nov 2018 10:49:51 +0000 GerlindeKettl]]> https://forum.misra.org.uk/showthread.php?tid=1459
The rationale of the rule says: “Similarly, reducing the visibility of a function by giving it internal linkage reduces the chance of it being called inadvertently.” So, I've interpreted this rule as "if you use a function only in the translation unit where it is defined, make it static". But for example library functions are intended to be called by anyone who needs them and cannot be called inadvertently.

Could you please clarify what the correct interpretation is?]]>
The rationale of the rule says: “Similarly, reducing the visibility of a function by giving it internal linkage reduces the chance of it being called inadvertently.” So, I've interpreted this rule as "if you use a function only in the translation unit where it is defined, make it static". But for example library functions are intended to be called by anyone who needs them and cannot be called inadvertently.

Could you please clarify what the correct interpretation is?]]> <![CDATA[Rule 8.3: int n[4] vs. int n[] ?]]> https://forum.misra.org.uk/showthread.php?tid=1398 Tue, 06 Feb 2018 14:46:49 +0000 swestin]]> https://forum.misra.org.uk/showthread.php?tid=1398
Code:
int n[4];


int n[];
]]>
Code:
int n[4];


int n[];
]]> <![CDATA[Rule 8.5: Declarations vs Redeclarations in MISRA C versus MISRA C++]]> https://forum.misra.org.uk/showthread.php?tid=1321 Thu, 02 Mar 2017 12:45:06 +0000 RichardC]]> https://forum.misra.org.uk/showthread.php?tid=1321
Quote: For the purposes of this standard, in headline rule text a
declaration is the first introduction of a name into a translation
unit. All subsequent “declarations” (as per ISO/IEC 14882:2003 [1]
§3.2(1)) are re-declarations.

This appears to differ from the MISRA C 2012 interpretation. Rule 8.5
includes the text:

Quote:... shall be declared once in one and only one file.

According to the MISRA C++ glossary entry, the use of "once" in the headline
text is redundant, as any additional declarations are "re-declarations".

Is the MISRA C meaning intended to be different to that of MISRA C++ 2008?

If so, could you provide an example where it is dangerous to use re-declarations?]]>
Quote: For the purposes of this standard, in headline rule text a
declaration is the first introduction of a name into a translation
unit. All subsequent “declarations” (as per ISO/IEC 14882:2003 [1]
§3.2(1)) are re-declarations.

This appears to differ from the MISRA C 2012 interpretation. Rule 8.5
includes the text:

Quote:... shall be declared once in one and only one file.

According to the MISRA C++ glossary entry, the use of "once" in the headline
text is redundant, as any additional declarations are "re-declarations".

Is the MISRA C meaning intended to be different to that of MISRA C++ 2008?

If so, could you provide an example where it is dangerous to use re-declarations?]]> <![CDATA[Rule 8.3 type qualifier]]> https://forum.misra.org.uk/showthread.php?tid=1282 Fri, 07 Oct 2016 01:38:21 +0000 Motozo Mario Ikeda]]> https://forum.misra.org.uk/showthread.php?tid=1282
Should we think "Type qualifier" includes "Type specifier"?

Thank you,
Mario Ikeda]]>
Should we think "Type qualifier" includes "Type specifier"?

Thank you,
Mario Ikeda]]> <![CDATA[Rule 8.4 - main function]]> https://forum.misra.org.uk/showthread.php?tid=1237 Wed, 20 Apr 2016 16:44:25 +0000 delta_controls]]> https://forum.misra.org.uk/showthread.php?tid=1237
Thanks.]]>
Thanks.]]> <![CDATA[Rule 8.4: Prototype for function with internal linkage required?]]> https://forum.misra.org.uk/showthread.php?tid=1212 Wed, 04 Nov 2015 14:51:53 +0000 aletomm]]> https://forum.misra.org.uk/showthread.php?tid=1212 internal linkage?

While MISRA-C 2012 rule 8.4 is very explicit about prototypes for functions with external linkage, we have not found a corresponding rule for internally linked functions.

Our static analysis tool takes the simplistic approach that prototypes are required in any case due to MISRA-C 2004 8.1 rule. I like to challenge its reasoning.

Thanks.]]> internal linkage?

While MISRA-C 2012 rule 8.4 is very explicit about prototypes for functions with external linkage, we have not found a corresponding rule for internally linked functions.

Our static analysis tool takes the simplistic approach that prototypes are required in any case due to MISRA-C 2004 8.1 rule. I like to challenge its reasoning.

Thanks.]]> <![CDATA[Rule 8.10, I don't understand the Rationale]]> https://forum.misra.org.uk/showthread.php?tid=1198 Wed, 05 Aug 2015 15:45:48 +0000 fpeelo]]> https://forum.misra.org.uk/showthread.php?tid=1198
However, this is also not defined for static functions: "Making a function an inline function suggests that calls to the function be as fast as possible. The extent to which such suggestions are effective is implementation-defined." (I'm using a draft of the C99 standard, http://www.open-std.org/JTC1/sc22/wg14/w.../n1256.pdf and this is 6.7.4.5. Footnote 121 spells it out more clearly: "For example, an implementation might never perform inline substitution...".)

So the behaviour of static inline functions is undefined in the same way as inline functions with external linkage.

It has been suggested that inline functions defined in header files should be defined with static linkage. Paragraph 6.7.4.3 of the above pdf says external linkage cannot reference indentifiers with internal linkage, but paragraph 6.7.4.6 says that any function with internal linkage can be inlined. So if an inline function is declared static, it can have local static variables. But there will be a different instance of the inline function for each .c file which includes the header with the function's definition, and each would have its own static variables! Effectively, you have a function definition with a static variable, the value of which differs depending on where it is called from. This will surely be unexpected behaviour to some programmers, and is therefore dangerous.

Was this considered when specifying that all inline functions should be static? Or is the draft wildly different from the final C99 spec?]]>
However, this is also not defined for static functions: "Making a function an inline function suggests that calls to the function be as fast as possible. The extent to which such suggestions are effective is implementation-defined." (I'm using a draft of the C99 standard, http://www.open-std.org/JTC1/sc22/wg14/w.../n1256.pdf and this is 6.7.4.5. Footnote 121 spells it out more clearly: "For example, an implementation might never perform inline substitution...".)

So the behaviour of static inline functions is undefined in the same way as inline functions with external linkage.

It has been suggested that inline functions defined in header files should be defined with static linkage. Paragraph 6.7.4.3 of the above pdf says external linkage cannot reference indentifiers with internal linkage, but paragraph 6.7.4.6 says that any function with internal linkage can be inlined. So if an inline function is declared static, it can have local static variables. But there will be a different instance of the inline function for each .c file which includes the header with the function's definition, and each would have its own static variables! Effectively, you have a function definition with a static variable, the value of which differs depending on where it is called from. This will surely be unexpected behaviour to some programmers, and is therefore dangerous.

Was this considered when specifying that all inline functions should be static? Or is the draft wildly different from the final C99 spec?]]> <![CDATA[8.3 and parameter name omitted.]]> https://forum.misra.org.uk/showthread.php?tid=1192 Wed, 01 Jul 2015 07:29:54 +0000 lovewar]]> https://forum.misra.org.uk/showthread.php?tid=1192
Code:
-- in t1.h
extern int foo(int);

-- t2.c
#include "t1.h"

int foo(int value) {  // here(parameter name do not match)
}
]]>
Code:
-- in t1.h
extern int foo(int);

-- t2.c
#include "t1.h"

int foo(int value) {  // here(parameter name do not match)
}
]]> <![CDATA[Rule 8.6: External declaration without definition]]> https://forum.misra.org.uk/showthread.php?tid=1188 Tue, 16 Jun 2015 12:10:57 +0000 Polyspacer]]> https://forum.misra.org.uk/showthread.php?tid=1188
Code:
extern signed short int Variable;

And I have the corresponding c-file MISRA_8.6.c, which uses the variable as input.
Code:
#include "MISRA_8.6.h"

signed short int A;

void main(void)
{

    /*8.6*/
    A = Variable;
    
}

The c-file defining the variable is out of scope. Is rule 8.6 violated by this setting or is another rule 8.x violated?]]>
Code:
extern signed short int Variable;

And I have the corresponding c-file MISRA_8.6.c, which uses the variable as input.
Code:
#include "MISRA_8.6.h"

signed short int A;

void main(void)
{

    /*8.6*/
    A = Variable;
    
}

The c-file defining the variable is out of scope. Is rule 8.6 violated by this setting or is another rule 8.x violated?]]> <![CDATA[Rule 8.4 the combination of the tentative definitions]]> https://forum.misra.org.uk/showthread.php?tid=1164 Thu, 12 Mar 2015 08:12:07 +0000 satoshi]]> https://forum.misra.org.uk/showthread.php?tid=1164
Code:
int i;  /* treated as declaration ? */
int i;  /* treated as definition ? */

or...
If only tentative definitions exists, we should consider that the compatible declaration is not exist?]]>
Code:
int i;  /* treated as declaration ? */
int i;  /* treated as definition ? */

or...
If only tentative definitions exists, we should consider that the compatible declaration is not exist?]]>