Welcome to the MISRA discussion forum

As stated and taken literally, this rule might be interpreted as requiring all identifiers used in any preprocessing directive be derived from a previous #define (is this the meaning of \"macro identifier\")?

Instead, I understand the rule as only requiring all identifiers used in the controlling constant-expression of #if and #elif preprocessing directives to be defined before use (unless the identifier is used as the operand of the defined() operator). However, identifiers used in the replacement-list of a #define preprocessing directive need NOT be \"defined before use\" as they may be ordinary identifiers and not defined by any #define preprocessing directive.

Otherwise, the identifier in a #define preprocessing directive itself could technically be interpreted as not meeting this rule, as the identifier isn't fully defined until after the directive has been processed. Thus, the only practical preprocessing directives covered by this rule appear to be #if and #elif directives.


As such, the rule might be more clearly stated as:

Quote:All identifiers used in the controlling constant expression of #if or #elif preprocessing directives shall be #defined before use, unless the identifier is an operand of the defined() operator.

Hi friends,

my question is same as the subject line

is 'Open C' 'MISRA C' compliant?

thanks n regards
Mukesh

1998 Rule 29 states, \"[i]t would be incorrect to initialize the tag with an initializer which did not match the structure declared for that tag.\"

What does it mean to \"initialize the tag\"?

Hello,

I am new to MISRA-C rules and in the code I am working on, there this kind of constructs :

I'm working with some legacy code and part of my job is to modify it to comply with the MISRA standard. A large portion of the code relies on macros such as this one:

[code]#define CURRENT_LARGE_SHIFT (18L)
#define CURRENT_LARGE_SCALE(v) (int32_t)(v * (1L

In misraC-2004 when starts section 6.11 - Pointer type Conversion says the following:

\"Conversions involving pointer types require an explicit cast except when:
The conversion is between a pointer to object an a pointer to void....\"

my question is if this example is compliance with that.

Just wondering what is the best way to define a boolean type for MISRA and most importantly what to define TRUE and FALSE as.

Some thoughts:

typedef unsigned char boolean_t
#define TRUE (0==0)
#define FALSE (!0)

Thanks.

Is there a template of the required Compliance Matrix available?

I would like to see such a matrix include the rule synopsis as well as it's ID, so that it is easy to comprehend.

Having purchased the MISRA-C 2004 PDF, I find that it is protected such that I cannot copy the contents of Appendix A as a good starting point.

Regards
Dave Banham

Hi,

I have a question regarding the use of Void pointers.

Rule 11.2 is the rule that applies (Conversions shall not be performed between a pointer to object and any type other than an integral type, another pointer to object or a pointer to void).

My first question is:
How do you define \"a pointer to object\"?
By this, do you mean structure, derived types?
I couldn't see any definition for this in the MISRA text.

My second question is:
This rule allows the conversion of a pointer from one type to void. (i.e. to a NULL_PTR to allow for error checking)
I think that this rule also prohibits the use of a defined void ptr, converting this to point to an array or other obect, is this correct?

i.e. the following is illegal:

void *pv_my_void_ptr = NULL_PTR;
u16 *pu16_my_int_ptr = (u16 *)pv_my_void_ptr;

As this would make the checking of alignment (i.e. Rule 11.4) impossible as well as hiding the original type pointed to?

Many Thanks for your consideration.

Mike.

I am working as a Software Quality Engineer at Siemens VDO in France and we are currently trying to document the consequence(s) of not respecting each of the MISRA rules, in order to make our developers aware of the risk(s). Sometimes this task is quite easy and sometimes less. So I am looking for some documentation that could help us reaching our objective. Today we are still using MISRA 1998, so I am more interested in documents dealing with the correponding rules, but it would also help for the future if some documents on MISRA 2004 exist.

Thanks for Help,

NM