Welcome to the MISRA discussion forum

I am trying to understand this rule and need someone to clarify its exact meaning.

which of the following are violations of Rule 12.6?

Need clarification on rule 5.1 (equivalenet to rule 11 in MISRA C1):

Does this rule disallow to use identifier that has more than 31 characters? Even though the first 31 characters are guaranteed to be distinct.

Thanks,

quangp

According to source code below, please kindly help me to clear understanding whether where are the implicitly cast and they will cast to what type?

Warning: Unsuffixed integral literal implicitly cast to another type.


Source code
struct {
unsigned char multiple: 1;
unsigned char event: 1;
unsigned char checksum: 1;
unsigned char conditional: 1;
} flag;
...

void transmit(void)
{
…
if (flag.conditional == 1) { [color=red][b]

Is the usage of ternary operator (? :) inside a C macro violation of rule 19.4. For e.g. the following function-like macro

#define abs(x) (((x) >= 0) ? (x) : -(x))

According to Rule 19.4 - C macros shall only expand to a braced initialiser, a constant, a parenthesized expression, a type qualifier, a storage class specifier or a do-while construct.

Does the above function-like macro conform to rule 19.4?

I have some doubt about the integral promotion whether how integral promotion's rule perform with the unsuffixed constant (hexadecimal).
Example:

16bit ECU
0xffff -----> Will it promote to \"int\" or \"unsigned int\"?
0xffffffff -----> Will it promote to \"int\" or \"unsigned int\"?

32bit ECU
0xffff -----> Will it promote to \"int\" or \"unsigned int\"?
0xffffffff -----> Will it promote to \"int\" or \"unsigned int\"?

Who know how does it perform with hexadecimal.
Please kindly give me the answer.

Thanks in advance,
Warawut.

The rule 1.1 deals with limits defined in chapter 5.2.4 of ISO-9899:1990 norm.

But for the #include preprocessing directive, the 9899:1999 (and so, I suspect that the C90 is more restrictive) specify in chapter 6.10.2 some restriction (limits) about the sequence placed between the \" \" or < > delimiters:

The implementation shall provide unique mappings for sequences consisting of:
- one or more digits (no case sensitive)
- followed by a period
- followed by a single letter.
- The mapping is restricting to eight significant characters before the period.

So if the sequence between \" and < > delimiters is specified, then the header file names are impacted.

I would like to know if it is MISRA compliant to have a header file name with more than 8 characters before the period ?
(Example: FooComponent_Api.h)


Thanks in advance for your answer.

Rule 20.9 says that the input/output library shall not be used in production code.

We can not use the function open because is not ANSI C. Which would be the alternative to open a file instead of fopen?

Thanks.

What are the possible scenarios in which Rule 2.1 will be violated?

Rule allows for Macros, C-functions and Assembly functions.

If any assembly code is used directly it will be reported as an compliler error for undefined identifier etc.

Rule 10.3 requires a \"complex expression\" of integer type only be explicitly cast to a NARROWER type.

Rule 10.5 requires that bitwise operator RESULT be immediately cast to the underlying type (NOT a NARROWER type).

Based on the discussion in 6.10.5, a shift-expression IS considered a \"complex expression\" such that rule 10.3 should apply to rule 10.5? If so, doesn't this cast back to the underlying type violate rule 10.3?

The primary motivation of this question is that I think rule 10.3 should prohibit an explicit cast to a WIDER type, rather than only allow a cast to a NARROWER type. This seems to fit better with 6.10.3's discussion under \"evaluation type confusion\" (p. 38), as well as 6.10.1's \"to change the type in which subsequent arithmetic operation is performed\" statement.

It might be preferred that an expression use the implicit conversion rather than explicitly casting to the underlying type -- but should explicitly casting to the underlying type be prohibited by rule 10.3? Sometimes, the cast to the underlying type may be the same as the actual (promoted) type of the expression, and other times the cast to the underlying type is a conversion of the promoted type back to the underlying type. This depends on the types and the implementation-defined sizeof(int).

Some examples:

(1) Should:
[code]U16 = (uint16_t)((uint16_t)U8

I recognize that \"The order in which # and ## operations are evaluated during macro substitution (6.10.3.2, 6.10.3.3).\" [ISO C 9899:1999 J.1 Unspecified behavior] is UNSPECIFIED behavior.

However, what is the real issue with the order of evaluation being unspecified? I realize that rule 19.13 goes even further than MISRA-C:1998 and advises that these operators not even be used at all. However, I'm wondering if someone can provide an example where the order of evaluation matters?

The only example I can think of is: