Welcome to the MISRA discussion forum

I have the following patterns, anybody please kindly give me some advises on them.

/*pattern1*/
int counter;
for (counter = 0; counter < 100; counter++)
{...}
...
counter = a*b;

Hi

Rule 13.5 (required) states: \"The 3 expressions of a for statement shall be concerned only with loop control\", and
\"First expression: initialising the loop counter.
Second expression: shall include testing the loop counter, and optionally other loop control variables.
Third expression: increment or decrement of the loop counter.\"

The implication would appear to be that for() loops should only be used where there is a loop counter. Is that correct, or could you (for example) use a for() loop without a loop counter, in which case there wouldn't be a first expression?

Is the idea to restrict C's for() usage to that of Pascal's ie.

for var := first [ to | downto ] last do ...

? I'm Ok with this, but I feel that either I'm missing something or the rule isn't explicit enough about what for() can and can't be used for.

Regards
John
NEC Technologies (UK)

Can any one tell me how to determine the underlying type of a bit-field? We need to know in order to incorporate testing for MISRA 2 compliance in our product.

You will notice that a few questions have been asked about the rules.

The MISRA C Working Group will review such questions from time to time and, where appropriate, give a considered response. Such a response will be posted under the name \"MISRA Reply\".

Please note that as MISRA is a voluntary activity, we may not be able to respond to every question; nor to guarantee responding to questions within a particular timescale. However, we do intend to post answers to the questions on a semi-regular basis from this time onwards.

We have been asked a number of questions about solutions and workarounds for various things that are prohibited in both MISRA C1 and MISRA C2 such as using malloc, calloc, etc. for dynamic memory allocation.

Neither MISRA or any member of the MISRA C Working Group will give any guidance or approval to any deviation or \"workaround\". Any advice that may be given by any individuals associated with MISRA C is entirely personal and is not to be seen as a comment from MISRA or the MISRA C Working Group. In general the advice we would give is:

Where you have decided it is not possible to comply with a rule you should raise a deviation giving your reasons and justifications for doing so. You will have to take documented responsibility for your own deviations.

Read Section 4 (of MISRA-C:2004) on using MISRA C, specifically section 4.3.2 on deviations which outlines how to use deviations.

In general deviations should be as local as possible and as specific as possible and must be subject to sign-off for each deviation (or class of deviation).

Remember YOU will have to take responsibility for your deviations.

Funtions with parameter of type char as for example \"strcpy\" I can not use signed or unsigned char. Eventhoug the compiler specifies that char is signed, whenever you call strcpy with signed char, there is a compilation error, but if we use the parameter of type char, then we violate rule 14. Does this mean that we must generate our own string manipulation functions?

I have made some presumptions regarding the MISRA 2004 concept of Underlying Type. Do correct me if I am wrong in these presumptions.

1. Explicit casts change an expression's underlying type
2. The Standard is not concerned with an expression's underlying type if any of its sub-expressions violate a required underlying type-related rule
3. Implicitly converting an expression (excluding promotions) change its underlying type
4. Effectively Boolean expressions have underlying type of int (see commentary in MISRA 2004, 6.10.2)
5. Enums and enumerations constants have underlying type of int (see C90 Standard, Clause 3, Section 1, Sub-section 3, Part 3)

Does anyone see a problem with any of these?

Expanding upon the example in the MISRA 2004 Standard for 14.3:


#define WHATABOUTTHIS /* Um */ ;
#define ORTHIS
#define ANDTHISTOO /* Well, I, uh... */

void f()
{
; /* OK */
/* Not OK */ ;
;/* Not OK */
WHATABOUTTHIS
ORTHIS;
ANDTHISTOO;
}

Which of the lines with macros, if any, violate the Rule?

Hi everybody,
did anyone of you try the digests function of this MISRA Bulletin Board ?
It seems to me that I got the message \"no posts\" (as usually :-) )although there was a post in a subforum of the misra-rules-forum on Dec 8 and I don't think I have been logged in since then.
(I selected weekly digest)

Erik

Does Rule 7.1, \"No octal constants (other than zero) and octal escape sequences shall not be used,\" permit the use of the null character, '\\0'? The normative and rule text exempt 0, per se, but make no mention about '\\0'. Prohibitting '\\0' runs, IMHO, contrary to the Principle of Least Surprise. Perhaps someone would show such kindness as to provide me with some clarity?

I appreciate your time in advance.