Welcome to the MISRA discussion forum

Good morning,

I'm (once more) thinking of implementing a static analysis tool for checking C sources against the MISRA-C:200 rules and release it as FLOSS (e. g. under GPL or a similar permissive license). However, I would need some questions answered before I can meaningfully undertake this task - I figure, that this is the best place to ask. What I would like to know is:

- Are there any legal restrictions when implementing a static analyser that claims to check the MISRA rules, i. e. is it even allowed to advertise this as a feature?
- Is it allowed to release such an analyser under a FLOSS license? The only problem I can think of is, that it is in principle possible to "reverse engineer" the rules out of the tool's source code, which could be seen as distributing the guidelines "for free".
- If a FLOSS release is permitted, are there any legal obligations to inform the MISRA Consortium of the release and subsequent additions to the tool (e. g. implementation of further MISRA rules)?

If someone can think of additional problems considering MISRA and FLOSS, don't hesitate to mention them (I am by no means a FLOSS license expert, those are just the problems I can immediately see).

Many thanks in advance for all pointers and answers.

Best Regards,

Peter

Given this example

Suppose I have two functions:

The second part of Rule 12.6 says that:
"Expressions that are effectively Boolean should not be used as operands to operators other than ..."
The list of the allowed operators has been corrected in TC1 to include &&, ||, !, =, ==, != and ?:

What about the function call operator () ?

If a Boolean value (by enforcement or by construction) is used as an argument to a function having a parameter whose type is Boolean (by enforcement), are we violating Rule 12.6? For instance:

Hello,

my compiler find in the following code a MISRA violation 17.4 at the last view code lines. Is this correct? If yes, please tell me how to solve the above mentioned code. In my opinion there is no MISRA rule 17.4 violation.

MISRA rule 7.1 says don't use octal constants, and gives good reasons.
But code which sets and uses constants which represent Linux file permissions (see, for example, http://www.zzee.com/solutions/linux-perm...ml#numeric), are necessarily octal and code is more readable in that case in octal -- the "native" format for such constants.

Of course an octal number can be written, with the same digits, as hexadecimal, and that would meet the MISRA constraint. But IMHO would not meet the spirit of this rule, which is to avoid writing digits outside the base of the number by mistake. Writing a Linux file permissions constant as hex would mean that by mistake the developer could write a digit between 8 and F, and static analysis (compiler etc) would not catch it because it's legal hex. But illegal file permission digit.

Would people see this as a good place for a deviation from MISRA rule 7.1?

Hi,
Given the following code:

This is a C99 feature.

Will Misra- C3 support it ?

In rule 16.8 is stated
All exit paths from a function...
whereas rule 14.7 states
A function shall have a single point of exit...

Is there a difference between "exit path" and "point of exit"? If not, should rule 16.8 be interpreted as beginning with "The single point of exit from a function..."?

Regards,

The rule states that the types for a function declaration and definition must be token-for-token identical. How literally should this rule be taken. I have two cases where this rule seems to conflict with normal or good practice.

1. In a function definition, a 'const' qualifier is often included for parameters passed by value as a promise that the implementation will not modify these parameters. This qualifier cannot be included in the declaration. For example:

template
T low_bits_mask(unsigned n);

template
T low_bits_mask(const unsigned n) {
return ~((~static_cast(0))