<![CDATA[MISRA Discussion Forums - 8.1 A standard C environment]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 20:03:06 +0000 MyBB <![CDATA[About Appendix H of MISRA C: 2012]]> https://forum.misra.org.uk/showthread.php?tid=1511 Tue, 15 Oct 2019 00:18:24 +0000 Takuya Nishimura]]> https://forum.misra.org.uk/showthread.php?tid=1511
I have some questions about Appendix H of MISRA C: 2012.

Appendix H states that C90 id and C99 id are based on C90 and C99 standard. Therefore, I thought there was only one C90 and C99 standard, but the reference lists multiple C90 and C99 standards. Which standard is used to create the table in Appendix H?

Also, C90 and C99 Standard are not assigned numbers such as C90 id and C99 id. How were the C90 id and C99 id numbering decided?]]>
I have some questions about Appendix H of MISRA C: 2012.

Appendix H states that C90 id and C99 id are based on C90 and C99 standard. Therefore, I thought there was only one C90 and C99 standard, but the reference lists multiple C90 and C99 standards. Which standard is used to create the table in Appendix H?

Also, C90 and C99 Standard are not assigned numbers such as C90 id and C99 id. How were the C90 id and C99 id numbering decided?]]> <![CDATA[Why is rule 1.2 classified as undecidable?]]> https://forum.misra.org.uk/showthread.php?tid=1438 Fri, 13 Jul 2018 06:31:11 +0000 dg1980]]> https://forum.misra.org.uk/showthread.php?tid=1438 It is even possible with some compilers (e.g. a strict mode)?]]> It is even possible with some compilers (e.g. a strict mode)?]]> <![CDATA[Rule 1.3 - Taking address of near auto variable]]> https://forum.misra.org.uk/showthread.php?tid=1420 Mon, 30 Apr 2018 08:41:49 +0000 Francois]]> https://forum.misra.org.uk/showthread.php?tid=1420
PC-Lint warn me that i'm using the address of a near auto variable.

My code looks like this:
Code:
/* static var */
static int16_t MySignVar = 0;

StatusType tMyfunc(void)
{
   uint16_t MyUnSignVar = 0U;
   StatusType ReturnValue;
  
   ReturnValue = tSomefunt(Parameter_1, &MyUnSignVar ); /* Note 934: Taking address of near auto variable... [MISRA 2012 Rule 1.3, required]... */
  
   /* MyUnSignVar is always positive */
   MySignVar += (int16_t)MyUnSignVar ;
  
   return (ReturnValue);
}

Could you help me to handle this issue?]]>
PC-Lint warn me that i'm using the address of a near auto variable.

My code looks like this:
Code:
/* static var */
static int16_t MySignVar = 0;

StatusType tMyfunc(void)
{
   uint16_t MyUnSignVar = 0U;
   StatusType ReturnValue;
  
   ReturnValue = tSomefunt(Parameter_1, &MyUnSignVar ); /* Note 934: Taking address of near auto variable... [MISRA 2012 Rule 1.3, required]... */
  
   /* MyUnSignVar is always positive */
   MySignVar += (int16_t)MyUnSignVar ;
  
   return (ReturnValue);
}

Could you help me to handle this issue?]]> <![CDATA[Rule 1.3 and Appendix H.1]]> https://forum.misra.org.uk/showthread.php?tid=1345 Thu, 08 Jun 2017 09:50:36 +0000 xiangke]]> https://forum.misra.org.uk/showthread.php?tid=1345 If a particular undefined behaviour has no entry in the “Guidelines” column then an instance of that behaviour in a program is a violation of Rule 1.3.

I have a question:
Does it mean that we can fill "rule 1.3" in the blank cell in the "Guidelines" column.
or it mean that we can fill "rule 1.3" in all the cell in the "Guidelines" column?

So, if the answer is the second one, in conclusion,if an instant in your code violate a specific rule listed in the “Guidelines” column. then It shall also violate Rule 1.3.
if the answer is the first one, in conclusion, if an instant in your code violate a specific rule listed in the “Guidelines” column. But we don't say it violate Rule 1.3.
I am justly a little confused about the descrption.]]> If a particular undefined behaviour has no entry in the “Guidelines” column then an instance of that behaviour in a program is a violation of Rule 1.3.

I have a question:
Does it mean that we can fill "rule 1.3" in the blank cell in the "Guidelines" column.
or it mean that we can fill "rule 1.3" in all the cell in the "Guidelines" column?

So, if the answer is the second one, in conclusion,if an instant in your code violate a specific rule listed in the “Guidelines” column. then It shall also violate Rule 1.3.
if the answer is the first one, in conclusion, if an instant in your code violate a specific rule listed in the “Guidelines” column. But we don't say it violate Rule 1.3.
I am justly a little confused about the descrption.]]> <![CDATA[Rule 1.3 - What do people do to check this rule?]]> https://forum.misra.org.uk/showthread.php?tid=1269 Tue, 23 Aug 2016 14:04:45 +0000 delta_controls]]> https://forum.misra.org.uk/showthread.php?tid=1269
Of the 191 undefined behaviours listed in C99, there are 61 that have no associated MISRA guideline. Checking all of these is particularly labourious, especially as the list in Annex J is not numbered.

How do people go about checking conformity with this catch-all rule?

Does anyone globally deviate from this rule, since the most important and most likely behaviours are addressed by other guidelines and checking the others is not practical?

Thanks.]]>
Of the 191 undefined behaviours listed in C99, there are 61 that have no associated MISRA guideline. Checking all of these is particularly labourious, especially as the list in Annex J is not numbered.

How do people go about checking conformity with this catch-all rule?

Does anyone globally deviate from this rule, since the most important and most likely behaviours are addressed by other guidelines and checking the others is not practical?

Thanks.]]> <![CDATA[Clarification of rule 2.5]]> https://forum.misra.org.uk/showthread.php?tid=1168 Mon, 23 Mar 2015 09:26:12 +0000 anuj1085]]> https://forum.misra.org.uk/showthread.php?tid=1168
File.h:
================
#define abc 10
================

Case1:
File1.c include file.h but does not use abc
Is this a violation.

Case2:
File1.c include file.h but does not use abc
File2.c includes file.h and uses abc
Is this a violation with respect to file1.c as it includes the header file but does not uses the macro.]]>
File.h:
================
#define abc 10
================

Case1:
File1.c include file.h but does not use abc
Is this a violation.

Case2:
File1.c include file.h but does not use abc
File2.c includes file.h and uses abc
Is this a violation with respect to file1.c as it includes the header file but does not uses the macro.]]> <![CDATA[Clarification of rule 2.3 and 2.4]]> https://forum.misra.org.uk/showthread.php?tid=1166 Fri, 13 Mar 2015 11:53:51 +0000 anuj1085]]> https://forum.misra.org.uk/showthread.php?tid=1166
My query is whether the unused tag and unused types declared in "header" file are also violation of this rule. Example below to explain more:

content of test.h:

int16_t unusedtype (void)
{
typedef int16_t local_type;
return 67;
}

This header is included in test.c. Should the violations be reported on this.]]>
My query is whether the unused tag and unused types declared in "header" file are also violation of this rule. Example below to explain more:

content of test.h:

int16_t unusedtype (void)
{
typedef int16_t local_type;
return 67;
}

This header is included in test.c. Should the violations be reported on this.]]>