0

According to MISRA rule 13.5 the right hand operand of a logical && or || operator shall not contain persistent side effects. Our C-code is checked with PC-Lint, message 9007 (http://gimpel-online.com/MsgRef.html#9007).

We have code of the form

if((GET_SIGNAL1() < CONST_1) || (GET_SIGNAL2() == CONST_2) ) { dostuff(); }

GET_x are macros, well, getting signal x with some error handling, the later causing intended side effects. A rule deviation to MISRA 13.5 is given, now the question is how to suppress the respective messages.

Efforts so far: Since this is auto generated code I can't put in lint comments directly, putting the comments in through the generator is though and, primarily, hardly traceable.

--e{(9007))} in the macro definition would work, but we also have code like foo = GET_SIGNAL1(); which would cause a function wide deactivation.

Thought about -ecall, too, but it just checks the call itself, not the context of the macro (as I hoped).

Improve this question
4
  • As long as your GET_x functions are handling everything thrown it shouldn't be an issue. Do you have to actually repress the message to get a "clean" analysis? I would think you can show where this is properly handled in the methods and therefore the flag is a false alarm...
    – mutt
    Commented Aug 21, 2014 at 12:20
  • @mutt As far as I understand the problem, Lint is indicating even a possible violation due to the fact I'm calling a function like macro (although I'm not to sure about it). I could handle it if it was in the macro, not in it's context 'foo || macro'.
    – Lord_Gestalter
    Commented Aug 21, 2014 at 12:26
  • Yes I believe that is correct. Which means unless you call your functions separately and cast returns to variables and then put them in your statement it will still throw that flag. Which I would just make sure that your macro always returns something valid for the comparison instead of throwing any errors.
    – mutt
    Commented Aug 21, 2014 at 12:29
  • @mutt I know. I should have mentioned that in some modules (the one I care for at the moment) ... well, it's not allowed to use local variables (much). I'm not even in the position to model or alter the tool chain. Just tring to help the software developers, and the only part I can affect is the lint configuration and the "glue code" like the macro definitions. Since nearly any signal is called by macro I guess you can imagine how the log file looks. A halfway "clean" analysis would be appreciated.
    – Lord_Gestalter
    Commented Aug 21, 2014 at 12:39

2 Answers 2

Reset to default
1

Not sure if this will solve all the issues, but it should help some if you try to include SonarQube http://sonarqube.15.x6.nabble.com/ in your lint process/report. You should be able to customize the results a little more. I personally have not used this, but it seems to be where you are wanting to go.

Improve this answer
1
  • Not an answer to the question, but your assistance is highly appreciated ;-)
    – Lord_Gestalter
    Commented Aug 21, 2014 at 13:34
0

We intend to solve the proble above with two Lint runs:

  • 1st run with productive code and globally deactivated message 9007
  • 2nd run with stubbed macro without the intended side-effect, but nothing but message 9007 activated
Improve this answer
1
  • Won't accept this as answer, just for inspiration if you have a similar problem
    – Lord_Gestalter
    Commented Sep 3, 2014 at 5:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.