Hello.
My PC-LINT tool gives me an error of violating of rules 11.1, 11.2, 11.3, 11.4 (cast from unsigned char to pointer ) on the line 2:
line 1: unsigned char* ptr;
line 2: ptr=(unsigned char*)0x12;
The idea behind is that I want to initialize a pointer with a non-zero address in a MISRA-compliant style.
Thank you for the answer.
Best regards.
Hi,
You can cheat:
Code:
ptr = (unsigned char*)( (void*)0x12 );
This is compliant but IMHO should be a violation of the
spirt or the MISRA rules!
Certain
low level code will indeed violate MISRA rules, and a deviation can and should be raised.
Hello again.
I already tried the small "cheat" you advised me, but I get the same warning.
Best Regards.
PC Lint and many other checking tools have adopted the MISRA rules after laying out their warning concepts earlier (PC Lint exists since the middle of the eighties!). Unless a tool has designed/revised its warning system to exactly match MISRA's ideas on what is good and what is not, there will be some areas not properly covered, and other areas covered too restrictively.
Have a look in the 'au-misra2.lnt' file in your distribution, and look for the messages enabled for the various MISRA rules. For instance, for rule 11.1, warning 923 is activated. The rule forbids conversions between function pointers and non-integral types. Warning 923 of Lint warns about conversions between pointers and non-pointers. For observation of only rule 11.1, Lint is too restrictive. But the mapping has been created with the premise that it's better to warn too often than not at all.
Since the Lint configuration file for MISRA is a tool and not the law, if you find discrepancies you want to avoid, create your own version of the options file, or provide deviations in the source code, at your discretion.
And for the record: This is a restriction of all tools claiminng to "support MISRA" I have seen to date. The quality of the MISRA support is dependent on the warning granularity of the original product. And for instance, the concept of 'underlying type' was introduced by MISRA 2004; several tools still have difficulties in this area, because the concept was never in their architectures until MISRA 2004 came out.
Even if it's not much concrete help for your present situation, I hope the explanation helps clarify your options.
BR,
Johan
Thank you very much for your answer, Johan.
line 2 is indeed a violation of Rule 11.3. The rule text recognises that there are circumstances, such as accessing hardware features, in which it is necessary to cast an integer to a pointer.
The recommendation, as also made by William Forbes, is to deviate Rule 11.3 in this case. Note that a cast via (void *) is still a violation of rule 11.3