2

When programming micro-controllers, there sometimes are registers that need to be read in order to reset some flags. These registers are memory mapped and are declared as pointers to volatile in the code.

Assume the next snippet as example:

typedef volatile struct _Ifx_SCU
{
   ...
   uint32_t reg;
   ...
}Ifx_SCU;


#define MODULE_SCU ((*(Ifx_SCU*)0xF0036000u))


void foo(void)
{
   ... 

   MODULE_SCU.reg; /* Read required to reset bits in reg */

   ...
}

Here reg has to be read in order to reset it's bits, there is no other way to reset some bits other thatn reading them, So, MISRA rule checker is complaining that there is dead code and it's right.

My question is What would be an ALTERNATE way of reading and discarding **reg value in order to avoid having "dead code"?** Because using the method in the post Casting the results of a volatile expression to void which has a very similar situation, I still getting a MISRA c 2012 rule violation. I'm not able to change anything from the #define MODULE_SCU or the struct so a correct alternative method is the way to go.

I don't want to just silence the compiler casting to void as I read from this thread: What does void casting do? because if I cast to void then the optimizer may optimize away that read and that is not desirable.

Don't pay too much attention to the correctness of the snippet, I only included it to illustrate the question

Community
  • 1
  • 1
m4l490n
  • 1,592
  • 2
  • 25
  • 46
  • 1
    possible duplicate of [Casting the results of a volatile expression to void](http://stackoverflow.com/questions/23746870/casting-the-results-of-a-volatile-expression-to-void) – too honest for this site Aug 11 '15 at 20:12
  • @Olaf: This is not exactly a duplicate since I'm looking for an alternate way of doing it besides the shown in the referenced thread – m4l490n Aug 11 '15 at 20:13
  • Well, I think it is actually a dup. Because you are also asking if that is optimized away. Not sure what you mean with "I'm not able to change ...". You do not have to change the declarations. The accessed object is basically the same as yours. – too honest for this site Aug 11 '15 at 20:14
  • What do you mean with "alternate way? Alternative to the correct way? – too honest for this site Aug 11 '15 at 20:15
  • I mean another correct way – m4l490n Aug 11 '15 at 20:16
  • Because with the one shown I still getting a MISRA C 2012 error regarding dead code – m4l490n Aug 11 '15 at 20:16
  • The same crap checker you had trouble multiple times already? Please provide the error message. And already write an email to the vendor. – too honest for this site Aug 11 '15 at 20:19
  • @Olaf: yeah the same one. I'll write to the vendor definitely But it wouldn't hurt to know of an alternative method if anyone knows one. – m4l490n Aug 11 '15 at 20:22
  • 1
    This question should be, "Why is the MISRA rule checker flagging this as dead code?". That makes it clearer and avoids it being a dup – Glenn Teitelbaum Aug 11 '15 at 20:25
  • `typedef volatile struct _Ifx_SCU` declared this struct to be volatile, but what about the fields inside? are they lifted to volatile too? i am not sure. if not, that's a good reason to be dead code. things involving `volatile` should not be dead otherwise. personally, i used system specified all registers as volatile `uchar`, `uint` etc but never try such definition. – Jason Hu Aug 11 '15 at 20:48
  • @HuStmpHrrr: The fields belong to the `struct`. So, If the whole struct is `volatile`, the fields are too. Note that this is the same for all qualifiers and storage class specifiers. Why do you think it would be different from the `const` _qualifier_? – too honest for this site Aug 11 '15 at 21:22
  • "Why is the MISRA rule checker flagging this as dead code?" Because as Olaf said this tool has some serious problems. In fact the dead code rule (MISRA-C:2012 Rule 2.2) explicitly says: "Exception: A cast to void is assumed to indicate a value that is intentionally not being used. The cast is therefore not dead code itself. It is treated as using its operand which is therefore also not dead code." – Veriloud Aug 11 '15 at 22:44
  • @Olaf ok. sounds good. – Jason Hu Aug 11 '15 at 23:18
  • This is a quite common compiler/analyser problem. Possible work-around which means the same thing: `volatile uint32_t dummy = MODULE_SCU.reg;` – Lundin Aug 12 '15 at 10:34
  • @Lundin: I've tried also this and is complaining about not using "dummy". I mean, the problem with MODULE_SCU.reg is just passed to dummy – m4l490n Aug 12 '15 at 15:18
  • @m4l490n But it _is_ used, right there... seems that your tool doesn't understand the meaning of volatile or side-effects at all. – Lundin Aug 13 '15 at 06:20
  • Your code is not in violation of MISRA C:2012 - your tool is incorrectly flagging *volatile* access as dead code. – Andrew Aug 16 '15 at 08:31

2 Answers2

4

Here reg has to be read in order to reset it's bits, there is no other way to reset some bits other thatn reading them, So, MISRA rule checker is complaining that there is dead code and it's right.

Dead code is code that does nothing. Technically dead code is a statement that has no side effects. In this case the volatile keyword indicates that it is indeed doing something, it is reading memory and therefore reseting the bits, A definite side effect.

The volatile keyword also ensures that compliant optimizers do not remove that line.

So, in fact the MISRA rule checker is wrong, the code is perfectly fine as is and should not be flagged.

There is no need to find an alternate to the correct approach.

tshepang
  • 12,111
  • 21
  • 91
  • 136
Glenn Teitelbaum
  • 10,108
  • 3
  • 36
  • 80
  • 3
    @Veltas: Please state the part of the standard you come to this conclusion. [5.1.2.3p2+](http://port70.net/~nsz/c/c11/n1570.html#5.1.2.3p2) imply the opposite – too honest for this site Aug 11 '15 at 20:44
  • 1
    @Olaf odd that programmers have typos where they type whole keywords in error :) And don't worry about downvote, I figured it wasn't you – Glenn Teitelbaum Aug 11 '15 at 20:51
  • @GlennTeitelbaum: Freudian slip? :-) – too honest for this site Aug 11 '15 at 21:07
  • 1
    Upvote, I would just add the technical description of dead code is a statement that has no side effects - and usually indicates a mistake. In this case there is no dead code. I would not be surprise the checker ignore volatile altogether, this would lead to a lot of "unreachable code" violations as well. – Veriloud Aug 11 '15 at 22:59
3

The correct way to read an object and discard the result is:

(void)object;

The cast is actually not necessary, but might keep the compiler from complaining (not sure about MISRA actually). FYI: it is an expression-statement.

If object is qualified volatile, the access may not be optimized away by the compiler, as this keyword tells the compiler that there is a side-effect, even if the compiler does not see it. That the cast applies to the result of the expression (the "read"), not the object, so it does not remove the qualifier as your comment implies.

The MISRA-checker should not complain, as the line actually does something. (That is implied by the volatile qualifier). If the tool complains anyway, trash it. Even more as this is not the first time you appear to have trouble with it.

tshepang
  • 12,111
  • 21
  • 91
  • 136
too honest for this site
  • 12,050
  • 4
  • 30
  • 52
  • is `(void)` truly required for a `volatile`, or is that just a bandage for non-complient warnings – Glenn Teitelbaum Aug 11 '15 at 20:59
  • @Veltas: Thanks; feel free to edit such typos, I have a crappy keyboard;-) – too honest for this site Aug 11 '15 at 21:02
  • @GlennTeitelbaum: Actually, the expresion as such is sufficient (use that myself), but some compilers might warn, so just play safe. Just added details. – too honest for this site Aug 11 '15 at 21:03
  • FYI OP mentions that casting to `void` results in the same error as before, so is not a work-around. Obviously your main advice is still correct: ditch the tool. – Veltas Aug 11 '15 at 21:38
  • @Veltas: "OP mentions that casting to void results in the same error as before ..." No wonder it results in the same **complain**. But with or without, it is no **error** and no reason to actually complain. Therefore the last paragraph of my answer applies. – too honest for this site Aug 11 '15 at 21:41
  • @Olaf: I don't disagree with your question at all, I'm just saying in response to: "If the tool complains anyway": the tool *does* complain, and indeed OP should trash it. – Veltas Aug 11 '15 at 22:12
  • @Olaf - Correct, however, I would argue with a very bad tool its harder to blindly follow MISRA Rules - which is BTW (according to the process activities added in MISRA-C:2012) actually non-compliant development ;-) – Veriloud Aug 11 '15 at 22:50
  • @Veriloud: "to blindly follow ..." is **always** recipe for failure, not even limited to programming. My idea after the first questions from OP was to make him think on his own **...** (I better stop here) – too honest for this site Aug 12 '15 at 12:38