Skip to main content
WM_IR
Associate III
June 10, 2021
Solved

assignment discards volatile qualifier problem

  • June 10, 2021
  • 6 replies
  • 9357 views

I have a SPI Receive Interrupt function. where I have use *pRxBuffer as a volatile. But, I get the error of "assignment discards volatile qualifier". As attached in the figure below. How do I fix that line to make sure the warning will go away?

0693W00000BadmeQAB.png

This topic has been closed for replies.
Best answer by TDK

It should be enough to just cast it to a non-volatile pointer directly.

pSPIHandle->pRxBuffer = (uint8_t *) pRxBuffer;

6 replies

waclawek.jan
Super User
June 10, 2021

An ugly but working solution is to cast to integer type and then back to pointer type. I use uintptr_t for that purpose.

pSPIHandle->pRxBuffer = (uint8_t *)(uintptr_t)pRxBuffer;

JW

TDK
TDKBest answer
June 10, 2021

It should be enough to just cast it to a non-volatile pointer directly.

pSPIHandle->pRxBuffer = (uint8_t *) pRxBuffer;

"If you feel a post has answered your question, please click ""Accept as Solution""."
WM_IR
WM_IRAuthor
Associate III
June 11, 2021

Yes this works. Could explain what is happening actually? I do not really understand. In the function SPIReceiveDataIT argument number 2, I put a volatile data type. Then, why I need cast back into non-volatile pointer again?

Ozone
Principal
June 11, 2021

> Then, why I need cast back into non-volatile pointer again?

The target variable might not need the volatile qualifier. That depends on the context, you need to know.

That cast is required to satisfy the pedantic MISRA compatibility, I think.

waclawek.jan
Super User
June 11, 2021

> It should be enough to just cast it to a non-volatile pointer directly.

That depends on particular toolchain and its settings, in case of the combination of gcc and settings I'm using it does not. I'm not going to investigate, which setting enforces this, maybe -Wpedantic?

> Then, why I need cast back into non-volatile pointer again?

This is a warning (maybe escalated to error through the -Werror). Ozone above explained the reason for this particular case.

The C standard suggests some warnings (standard calls them diagnostics) and allows the toolchain to emit any extra warnings at its discretion. The selection of operations deemed dangerous enough to warrant a warning is at the toolchains' creators personal perception (sometimes supported by a similarly dubious selection, such as MISRA mentioned by Ozone above).

In gcc, you can switch warnings selectively off, either through command-line switches https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html, through attribute selectively for a given function (see https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes "warning" attribute), or selectively for given source lines through a pragma (but this can be tricky if optimization is used, so I won't give a link here).

JW