shame on MISRA

I sometimes use 0xFFFFffff which is with a constant width font quite readable :-).

Paul

Well, if you can do it, good for you :). I can't. All hex constants have to be written in caps. What is more- supporters for MISRA 'no matter what' _and_ the caps rule - given this example - were unable to say, how many Fs they see. Yet, they still argue, that this is just a 'minor inconvenience'. MISRAtitis, I'd say. No 'common sense' here...

M.

Just use ~0U

~0 works pretty well for these purposes

...

True :). I can't recall the reason, why I didn't use it.

M.

There are two kinds of developers who create MISRA-compliant code:

1. Those who were told to by their pointy-haired boss; and
2. Those who understand the spirit of MISRA and think it can help them write better code.

From I've gathered from this discussion so far, and disregarding the overlap between 1 and 2, a lot of people seem to be saying that group #1 is big and therefore that MISRA is bad and/or useless.

Just like with any set of rules, you can follow them to the letter, or you can try to follow the spirit of it. Your example definately defeats the spirit of MISRA-C.

How can you trust a lawyer not to exploit a hole in the law?

As has been said before in this discussion: "In the end, the programmer must not just follow the rules, but also understand the reasoning behind them, and must apply the same philosophy to the rest of his work. It should not come as a surprise that a set of guidelines can be subverted by a sufficiently motivated person."

Yeah, now I can. It just doesn't matter. If I use ~0U it will trigger MISRA-C rule 10.1 (An integer constant expression with negative value is being converted to an unsigned type.) just as -1U does. No difference from MISRA-C check point of view. It is a better way- logical operators only, and this is a logical value- but it is not enough.

M.

In article , Boudewijn Dijkstra writes

I agree. I see many people spending effort on trying to circumvent the MISRA-C rules whilst technically sticking to them

The rules are there for guidance. They were put together by a group of people with a hell of a lot of real experience in critical systems.

It saddens me to see so many people trying to find ways to beat the rules rather than using them as guidance to write better code.

Exactly. You also see people being very stupid and doing things like the defines above rather than using a deviation and expelling why they are deviating.

I find is sad that so many programmers spend time and effort trying to subvert the rules rather than trying to become more professional SW Engineers

Maybe I'm being exceptionally dense this morning but What integer constant expression with a negative value?

Is this an automated check against the rules or a hand check?

Robert

How about ~(0U) and -(1U) ?

Well, having ~0U is not quite enough; I want to use it :). So I did: uint16_t some_variable = (uint16_t)(~0U); (effectively- all #defines, ...) to have 0xffff in some_variable. It was enough to trigger the rule.

It is an automated check. I'm not sure enough that my mind won't bend the rule, to do a hand check, sorry ;).

M.

Haven't checked that. I'm afraid there will be no difference; I'll check it tomorrow.

M.

Well, MISRA is a tool. IMHO there are two (at least) domains to describe the tool:

- safety,

- usefulness. IMHO- this tool is unsafe, because it can be _easily_ used in unsafe way (the pointy-haired boss...). And it is also useful- helping to make a better code. Just like a razor. Give it to the monkey and give it to the barber and see, what will happen ;).

True. But, after all, I am paid for MISRA-C compliant code, not for code that follows its spirit. Even if non-compliant code is commented, it's clear, what it does- it is still not compliant ((uint16_t)(~0U) ? Does anyone have any doubts what id does? And that it is safer that any possible work-around?). The compliant code, however obscure, is still compliant. Unfortunately, the 'faulty MISRA compliant' code is easier to write, than truly compliant code. Which means, that, given poor management, one will tend to write poor code as to increase his/hers productivity. Yes, this is management issue. Can't separate them (MISRA and management), sorry.

...

I'd add here, that sometimes rules shall not be applied, as following spirit may be against the letter.

M.

And why, the hell, is that?

Yes, but IMHO guidance means- we don't have to follow blindly, we can lift the rule if necessary.

I am requested to have no MISRA-C warnings in my code (see any spirit here?). Now, I have two ways of dealing with possible issues:

- make it compliant to the letter, forget the spirit,

- try to make it compliant to the spirit (hard way) and possibly make a deviation (pain in the neck). Now, I mostly choose the second option (against my short-term interests). So _sometimes_ I have to argue with my boss and convince him, that we should deviate, and my code takes _sometimes_ longer to write. Those, who follow the other way, are therefore easier to get along with, faster- shortly- better. Do you really think this positively motivates me to follow the spirit of MISRA?

Huh? Do you _really_ think there is _any_ reason to have those (now deleted) defines _except_ MISRA 'compliance'? Deviating is not easy. Takes time. Takes effort. Deadlines approaching. Why should I take overtime to do it?

...

Why? Why do this? What is in that for me? Will I be better payed?

M.

... snip ...

Ignoring Misra, that is not as accurate as "unsigned = -1", which will set all bits to one everywhere.

I still don't see an integer constant expression with a negative value.

OTOH any reason not to set up the variable during initialization (since it appears not to be const)?

some_variable = ~some_variable;

That should also get rid of the casts.

Robert

...

Are there situations, when ~0 won't set all 1s? The only one I can think of that late that could be dangerous is: unsigned long long var = ~0; Right?

M.

OK I ran a test using the following

extern unsigned char variable1; extern unsigned int variable2; extern unsigned short variable3;

variable2 = -1; variable2 = ~0U; variable2 = ~(unsigned int)0U; variable3 = ~0U;

I'm not using typedefs just to keep conflicting types clear and I've got the warning for that in the MISRA rules turned off since I'm using standard libraries and that rule is WAY to noisy then.

I get the following errors

| variable2 = -1; test2.c 46 Note 960: Violates MISRA 2004 Required Rule 10.1, Prohibited Implicit Conversion: Signed versus Unsigned

test2.c 46 Warning 570: Loss of sign (assignment) (int to unsigned int)

| variable2 = ~0U; test2.c 47 Note 960: Violates MISRA 2004 Required Rule 10.5, Operators '~' and '

I agree.

Good.

Point taken. Perhaps something can be added to the MISRA-C TC?

Only for S-Boxes in DES systems.

Life is a balance of many things. MISRA-C is not a solution on it's own.

Being more professional.