<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/">
	<channel>
		<title><![CDATA[MISRA Discussion Forums - 6.18 Structures and Unions]]></title>
		<link>https://forum.misra.org.uk/</link>
		<description><![CDATA[MISRA Discussion Forums - https://forum.misra.org.uk]]></description>
		<pubDate>Thu, 05 Nov 2026 15:13:16 +0000</pubDate>
		<generator>MyBB</generator>
		<item>
			<title><![CDATA[Violation for rule 109]]></title>
			<link>https://forum.misra.org.uk/showthread.php?tid=771</link>
			<pubDate>Tue, 07 Sep 2010 14:57:23 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.misra.org.uk/member.php?action=profile&uid=1205">klaus83</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.misra.org.uk/showthread.php?tid=771</guid>
			<description><![CDATA[Hello everybody,<br />
<br />
Does anybody know if rule 109: "Overlapping storage shall not be used" is violated by having two pointer variables pointing on the same address??<br />
My automated MISRA checker only looks for union declarations and definitions when checking this rule. <br />
<br />
<br />
Thanks, <br />
Klaus]]></description>
			<content:encoded><![CDATA[Hello everybody,<br />
<br />
Does anybody know if rule 109: "Overlapping storage shall not be used" is violated by having two pointer variables pointing on the same address??<br />
My automated MISRA checker only looks for union declarations and definitions when checking this rule. <br />
<br />
<br />
Thanks, <br />
Klaus]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[2 questions for rule 18.1]]></title>
			<link>https://forum.misra.org.uk/showthread.php?tid=692</link>
			<pubDate>Wed, 25 Nov 2009 09:22:51 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.misra.org.uk/member.php?action=profile&uid=815">pmhill</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.misra.org.uk/showthread.php?tid=692</guid>
			<description><![CDATA[The rule applies to structure definitions that are incomplete, but I see from exemplar suite file mc2_1801.c the following unexpected violation:<br />
<br />
   struct {<br />
      int8_t a;<br />
      int8_t b [ ];    /* Not Compliant - constraint error 6.5.2.1 */<br />
   } mc2_1801_st = { 1, { 2, 3, 4 } };<br />
<br />
Are you including as "incomplete" any structure that has a flexible array member?<br />
<br />
Apart from this, what other coding practice is left that might cause a problem?<br />
<br />
If the type is incomplete, a compile error will result from any attempt to create an object of that type or refer to its members or to compute sizeof, etc.<br />
<br />
So I cannot think of any legal C code that would be a violation of this rule.]]></description>
			<content:encoded><![CDATA[The rule applies to structure definitions that are incomplete, but I see from exemplar suite file mc2_1801.c the following unexpected violation:<br />
<br />
   struct {<br />
      int8_t a;<br />
      int8_t b [ ];    /* Not Compliant - constraint error 6.5.2.1 */<br />
   } mc2_1801_st = { 1, { 2, 3, 4 } };<br />
<br />
Are you including as "incomplete" any structure that has a flexible array member?<br />
<br />
Apart from this, what other coding practice is left that might cause a problem?<br />
<br />
If the type is incomplete, a compile error will result from any attempt to create an object of that type or refer to its members or to compute sizeof, etc.<br />
<br />
So I cannot think of any legal C code that would be a violation of this rule.]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[Rule 17.4 and Rule 14.7]]></title>
			<link>https://forum.misra.org.uk/showthread.php?tid=631</link>
			<pubDate>Mon, 02 Mar 2009 13:12:47 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.misra.org.uk/member.php?action=profile&uid=793">Kdasari</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.misra.org.uk/showthread.php?tid=631</guid>
			<description><![CDATA[Hi Folks,<br />
<br />
We appreciate the MISRA-C compliance. <br />
<br />
We are making our application code into the MISRA-C compliance and can you please clarify below questions.<br />
<br />
1./Rule 14.7:  This rule says that array indexing is only allowed for pointer arithmetic. We understand that if we manipulate the pointer we may end up some cases accessing the non existing memory but suppose even if we access through the index and index is beyond the size of array declaration here also we end accessing the  non existing memory , We have the below code and I think it is safe away of using? Can you please let us know the motivation of this rule and how indexing can avoid the error?  Also let us know that the below code is acceptable or not?<br />
<br />
void awe_vecAbs(<br />
        		const float * src, <br />
        		int           srcInc, <br />
        		float       * dst, <br />
        		int           dstInc, <br />
        		int           blockSize)<br />
{<br />
    			int i;<br />
<br />
    			for (i = 0; i &lt; blockSize; i++)<br />
    			{<br />
        			*dst = fabsf (*src);<br />
        			src = src + srcInc;<br />
        			dst = dst + dstInc;<br />
    			}<br />
<br />
)<br />
2./ Rule 14.7 says that the function should have the only one single exit but in some cases it is very difficult to compliance with this especially when we check for the error concealment. Please have a look at below code we still can use if ,else conditions but we end up having more checks like this which will degrade the system performance, Can you please let us know what way we can do this in better and motivation of this Rule?  <br />
                             if (currentObject == NULL)<br />
		{<br />
			return (E_NOT_OBJECT_POINTER);<br />
		}<br />
		id = awe_fwGetClassType(currentObject);<br />
		if (!IsClassValid(id))<br />
		{<br />
			return (E_NOT_OBJECT_POINTER);<br />
		}<br />
		*pObject = currentObject-&gt;pNextInstance;<br />
		if (*pObject == NULL)<br />
		{<br />
			return (E_NO_MORE_IOPINS);<br />
		}<br />
		*pClassID = awe_fwGetClassType(*pObject);<br />
	return (0);<br />
<br />
<br />
Best regards,<br />
Kishore.]]></description>
			<content:encoded><![CDATA[Hi Folks,<br />
<br />
We appreciate the MISRA-C compliance. <br />
<br />
We are making our application code into the MISRA-C compliance and can you please clarify below questions.<br />
<br />
1./Rule 14.7:  This rule says that array indexing is only allowed for pointer arithmetic. We understand that if we manipulate the pointer we may end up some cases accessing the non existing memory but suppose even if we access through the index and index is beyond the size of array declaration here also we end accessing the  non existing memory , We have the below code and I think it is safe away of using? Can you please let us know the motivation of this rule and how indexing can avoid the error?  Also let us know that the below code is acceptable or not?<br />
<br />
void awe_vecAbs(<br />
        		const float * src, <br />
        		int           srcInc, <br />
        		float       * dst, <br />
        		int           dstInc, <br />
        		int           blockSize)<br />
{<br />
    			int i;<br />
<br />
    			for (i = 0; i &lt; blockSize; i++)<br />
    			{<br />
        			*dst = fabsf (*src);<br />
        			src = src + srcInc;<br />
        			dst = dst + dstInc;<br />
    			}<br />
<br />
)<br />
2./ Rule 14.7 says that the function should have the only one single exit but in some cases it is very difficult to compliance with this especially when we check for the error concealment. Please have a look at below code we still can use if ,else conditions but we end up having more checks like this which will degrade the system performance, Can you please let us know what way we can do this in better and motivation of this Rule?  <br />
                             if (currentObject == NULL)<br />
		{<br />
			return (E_NOT_OBJECT_POINTER);<br />
		}<br />
		id = awe_fwGetClassType(currentObject);<br />
		if (!IsClassValid(id))<br />
		{<br />
			return (E_NOT_OBJECT_POINTER);<br />
		}<br />
		*pObject = currentObject-&gt;pNextInstance;<br />
		if (*pObject == NULL)<br />
		{<br />
			return (E_NO_MORE_IOPINS);<br />
		}<br />
		*pClassID = awe_fwGetClassType(*pObject);<br />
	return (0);<br />
<br />
<br />
Best regards,<br />
Kishore.]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[Why rule 18.1?]]></title>
			<link>https://forum.misra.org.uk/showthread.php?tid=629</link>
			<pubDate>Thu, 19 Feb 2009 23:11:49 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.misra.org.uk/member.php?action=profile&uid=350">exoson</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.misra.org.uk/showthread.php?tid=629</guid>
			<description><![CDATA[Please help me understand the reason for rule 18.1.  In the context of an "opaque pointer", one can properly make and use such a pointer to an incompletely typed structure.  Having the full structure declaration is not needed.  The committee has endorsed this in a previous post.<br />
<br />
What coding practice is left that might cause a problem?  If the type is incomplete, a compile error will result from any attempt to create an object of that type or refer to its members.<br />
<br />
OK, but even so, why not require it?  In header files, I like to code:<br />
struct something;  /* with a forward declaration, I can create pointers. */<br />
<br />
void foo (struct something *pointerToSomething);<br />
<br />
The prototype is valid even though "something" is of incomplete type.  If the #including .c file does not need anything other than the pointer, why require #including yet another header merely to get the (unused) full declaration and satisfy the rule?]]></description>
			<content:encoded><![CDATA[Please help me understand the reason for rule 18.1.  In the context of an "opaque pointer", one can properly make and use such a pointer to an incompletely typed structure.  Having the full structure declaration is not needed.  The committee has endorsed this in a previous post.<br />
<br />
What coding practice is left that might cause a problem?  If the type is incomplete, a compile error will result from any attempt to create an object of that type or refer to its members.<br />
<br />
OK, but even so, why not require it?  In header files, I like to code:<br />
struct something;  /* with a forward declaration, I can create pointers. */<br />
<br />
void foo (struct something *pointerToSomething);<br />
<br />
The prototype is valid even though "something" is of incomplete type.  If the #including .c file does not need anything other than the pointer, why require #including yet another header merely to get the (unused) full declaration and satisfy the rule?]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[18.4 Unions shall not be used...]]></title>
			<link>https://forum.misra.org.uk/showthread.php?tid=323</link>
			<pubDate>Mon, 13 Nov 2006 12:58:46 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.misra.org.uk/member.php?action=profile&uid=259">rahul_mishra</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.misra.org.uk/showthread.php?tid=323</guid>
			<description><![CDATA[Is it that unions can be declared or defined but not used? i.e.; Do we need to flag a violation even on the declaration or definition of the union? or is it only on the usage of it.]]></description>
			<content:encoded><![CDATA[Is it that unions can be declared or defined but not used? i.e.; Do we need to flag a violation even on the declaration or definition of the union? or is it only on the usage of it.]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[unnamed members of a structure]]></title>
			<link>https://forum.misra.org.uk/showthread.php?tid=317</link>
			<pubDate>Fri, 13 Oct 2006 04:37:21 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.misra.org.uk/member.php?action=profile&uid=259">rahul_mishra</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.misra.org.uk/showthread.php?tid=317</guid>
			<description><![CDATA[Please let me know \"<span style="font-weight: bold;" class="mycode_b">How do we access an unnamed member of a structure</span>\"?<br />
<br />
Its quite natural to use bitfields as unnamed members of a structure especially for padding. But, how do we access those unnamed members. Do we have to increment the pointer to access it? if yes, please illustrate it with an example.]]></description>
			<content:encoded><![CDATA[Please let me know \"<span style="font-weight: bold;" class="mycode_b">How do we access an unnamed member of a structure</span>\"?<br />
<br />
Its quite natural to use bitfields as unnamed members of a structure especially for padding. But, how do we access those unnamed members. Do we have to increment the pointer to access it? if yes, please illustrate it with an example.]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[18.1 All structure or union types shall be complete at...]]></title>
			<link>https://forum.misra.org.uk/showthread.php?tid=307</link>
			<pubDate>Mon, 18 Sep 2006 12:16:00 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.misra.org.uk/member.php?action=profile&uid=255">srogers</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.misra.org.uk/showthread.php?tid=307</guid>
			<description><![CDATA[<blockquote class="mycode_quote"><cite>Quote:</cite>18.1 All structure or union types shall be complete at the end of a translation unit. <br />
A complete declaration of the structure or union shall be included within any translation unit that refers to that structure. </blockquote>
<br />
If my interpretation of this rule is correct then it prohibits the use of opaque pointers. (I wish to use these to hide the contents of structures, so that access is only via certain functions.) <br />
<br />
Was the prohibition of opaque pointer use deliberate? If so what are the concerns?]]></description>
			<content:encoded><![CDATA[<blockquote class="mycode_quote"><cite>Quote:</cite>18.1 All structure or union types shall be complete at the end of a translation unit. <br />
A complete declaration of the structure or union shall be included within any translation unit that refers to that structure. </blockquote>
<br />
If my interpretation of this rule is correct then it prohibits the use of opaque pointers. (I wish to use these to hide the contents of structures, so that access is only via certain functions.) <br />
<br />
Was the prohibition of opaque pointer use deliberate? If so what are the concerns?]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[18.4 unions shall not be used]]></title>
			<link>https://forum.misra.org.uk/showthread.php?tid=257</link>
			<pubDate>Tue, 16 May 2006 12:31:13 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.misra.org.uk/member.php?action=profile&uid=211">Manni</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.misra.org.uk/showthread.php?tid=257</guid>
			<description><![CDATA[Hello<br />
<br />
I use unions in the following example. And I want to know, if in such a situation the use of unions is compliant or not compliant to MISRA-C:2004. Or if somebody has a better idea for a good implementation.<br />
<br />
<br />
<div class="codeblock"><div class="title">Code:</div><div class="body" dir="ltr"><code>Example_Ports.h /* eg. a processor library of a processor manufacturer */<br />
-----------FILE START----------------<br />
...<br />
...<br />
...<br />
#define PORTA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(*((volatile uint8_t *)(2000)))<br />
/* So with &#92;"PORTA&#92;" we get access to data content of PORTA (adress 2000), it is a unsigned char, 8 bits. The file and this line is given by the processor manufacturer */<br />
...<br />
...<br />
-----------FILE END----------------<br />
<br />
<br />
<br />
<br />
<br />
/*Example_Test.c /* the example c file*/<br />
-----------FILE START----------------<br />
...<br />
...<br />
...<br />
<br />
typedef union {<br />
&nbsp;&nbsp;uint8_t cb ;<br />
&nbsp;&nbsp;struct bits {<br />
&nbsp;&nbsp;&nbsp;&nbsp;uint8_t<br />
&nbsp;&nbsp;&nbsp;&nbsp;b0 : 1,<br />
&nbsp;&nbsp;&nbsp;&nbsp;b1 : 1,<br />
&nbsp;&nbsp;&nbsp;&nbsp;b2 : 1,<br />
&nbsp;&nbsp;&nbsp;&nbsp;b3 : 1,<br />
&nbsp;&nbsp;&nbsp;&nbsp;b4 : 1,<br />
&nbsp;&nbsp;&nbsp;&nbsp;b5 : 1,<br />
&nbsp;&nbsp;&nbsp;&nbsp;b6 : 1,<br />
&nbsp;&nbsp;&nbsp;&nbsp;b7 : 1 ;<br />
 } b ;<br />
}example_bitfield;<br />
<br />
<br />
#define B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.b7<br />
#define B6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.b6<br />
#define B5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.b5<br />
#define B4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.b4<br />
#define B3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.b3<br />
#define B2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.b2<br />
#define B1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.b1<br />
#define B0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.b0<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;#define bitf_porta&nbsp;&nbsp;(*((volatile example_bitfield*) &amp;PORTA))<br />
&nbsp;&nbsp;&nbsp;&nbsp;/* Typcast to easy and safty access to each bit, see next line */<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;#define porta_light bitf_porta.B5<br />
&nbsp;&nbsp;&nbsp;&nbsp;/* for a good identifier for the bit. which is for example for a light */<br />
<br />
<br />
int main(void)<br />
{<br />
&nbsp;&nbsp;&nbsp;&nbsp;uint8_t x;<br />
&nbsp;&nbsp;&nbsp;&nbsp;x = 0;<br />
<br />
/* Now we can easy use the bits of the ports of the processor manufacturer. eg: */<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;porta_light = 1;<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;x = porta_light;<br />
<br />
}</code></div></div><br />
A. What do you think of this little example. Good user, or bad work?<br />
<br />
B. Compliant to rule 18.4, a situation in which unions could be used? Or not. And then, how we could do it in a MISRA-C:2004 way?<br />
<br />
thanks a lot<br />
<br />
Best regards, <br />
Manni<br />
<br />
BTW: Big thanks for your help in my last threads. My MISRA Guide proceed.]]></description>
			<content:encoded><![CDATA[Hello<br />
<br />
I use unions in the following example. And I want to know, if in such a situation the use of unions is compliant or not compliant to MISRA-C:2004. Or if somebody has a better idea for a good implementation.<br />
<br />
<br />
<div class="codeblock"><div class="title">Code:</div><div class="body" dir="ltr"><code>Example_Ports.h /* eg. a processor library of a processor manufacturer */<br />
-----------FILE START----------------<br />
...<br />
...<br />
...<br />
#define PORTA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(*((volatile uint8_t *)(2000)))<br />
/* So with &#92;"PORTA&#92;" we get access to data content of PORTA (adress 2000), it is a unsigned char, 8 bits. The file and this line is given by the processor manufacturer */<br />
...<br />
...<br />
-----------FILE END----------------<br />
<br />
<br />
<br />
<br />
<br />
/*Example_Test.c /* the example c file*/<br />
-----------FILE START----------------<br />
...<br />
...<br />
...<br />
<br />
typedef union {<br />
&nbsp;&nbsp;uint8_t cb ;<br />
&nbsp;&nbsp;struct bits {<br />
&nbsp;&nbsp;&nbsp;&nbsp;uint8_t<br />
&nbsp;&nbsp;&nbsp;&nbsp;b0 : 1,<br />
&nbsp;&nbsp;&nbsp;&nbsp;b1 : 1,<br />
&nbsp;&nbsp;&nbsp;&nbsp;b2 : 1,<br />
&nbsp;&nbsp;&nbsp;&nbsp;b3 : 1,<br />
&nbsp;&nbsp;&nbsp;&nbsp;b4 : 1,<br />
&nbsp;&nbsp;&nbsp;&nbsp;b5 : 1,<br />
&nbsp;&nbsp;&nbsp;&nbsp;b6 : 1,<br />
&nbsp;&nbsp;&nbsp;&nbsp;b7 : 1 ;<br />
 } b ;<br />
}example_bitfield;<br />
<br />
<br />
#define B7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.b7<br />
#define B6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.b6<br />
#define B5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.b5<br />
#define B4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.b4<br />
#define B3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.b3<br />
#define B2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.b2<br />
#define B1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.b1<br />
#define B0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.b0<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;#define bitf_porta&nbsp;&nbsp;(*((volatile example_bitfield*) &amp;PORTA))<br />
&nbsp;&nbsp;&nbsp;&nbsp;/* Typcast to easy and safty access to each bit, see next line */<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;#define porta_light bitf_porta.B5<br />
&nbsp;&nbsp;&nbsp;&nbsp;/* for a good identifier for the bit. which is for example for a light */<br />
<br />
<br />
int main(void)<br />
{<br />
&nbsp;&nbsp;&nbsp;&nbsp;uint8_t x;<br />
&nbsp;&nbsp;&nbsp;&nbsp;x = 0;<br />
<br />
/* Now we can easy use the bits of the ports of the processor manufacturer. eg: */<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;porta_light = 1;<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;x = porta_light;<br />
<br />
}</code></div></div><br />
A. What do you think of this little example. Good user, or bad work?<br />
<br />
B. Compliant to rule 18.4, a situation in which unions could be used? Or not. And then, how we could do it in a MISRA-C:2004 way?<br />
<br />
thanks a lot<br />
<br />
Best regards, <br />
Manni<br />
<br />
BTW: Big thanks for your help in my last threads. My MISRA Guide proceed.]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[Questions about 18.3]]></title>
			<link>https://forum.misra.org.uk/showthread.php?tid=26</link>
			<pubDate>Mon, 28 Feb 2005 12:30:13 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.misra.org.uk/member.php?action=profile&uid=82">bigpan</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.misra.org.uk/showthread.php?tid=26</guid>
			<description><![CDATA[I have the following patterns, anybody please kindly give me some advises on them.<br />
<br />
/*pattern1*/<br />
int counter;<br />
for (counter = 0; counter &lt; 100; counter++)<br />
{...}<br />
...<br />
counter = a*b;     ]]></description>
			<content:encoded><![CDATA[I have the following patterns, anybody please kindly give me some advises on them.<br />
<br />
/*pattern1*/<br />
int counter;<br />
for (counter = 0; counter &lt; 100; counter++)<br />
{...}<br />
...<br />
counter = a*b;     ]]></content:encoded>
		</item>
	</channel>
</rss>