const volatile指针函数参数

Question

For a embedded SW project we need to use some const volatile TYPE * pointers. Now we have some calculation functions which are looking like following:

uint8 calc(const volatile uint8 *array, uint8 value) { ... }

The data of both variables is not changing during the function execution.

The calling code looks like following:

const volatile uint8 *array = (const volatile uint8 *)0x00010111;
uint8 value = 8;

uint8 result = calc(array, value);

The question is now, would be there a difference, if we design the calucation functions without volatile arguments:

uint8 calc(const uint8 *array, uint8 value) { ... }

For the call we cast away the volatile:

uint8 result = calc((const uint8 *)array, value);

Pros for the second solution are more flexibility: We can use the function also for non volatile variables. But does it make a difference, if we cast away the volatile and our compiler does some strong optimizations?

Answer 1

You can ALWAYS use the function with non-volatile arguments. Its just that the code in the function handles the given objects as if they were volatile (losing performance on the way, most likely). Its a bit hard to imagine what a function with volatile arguments ("because they might change without notice") could sensibly do. As you write, in your case the data doesn't change anyway, so the most flexible solution is to declare the parameters const and forget about volatile.

And pretty please, use "uint8_t" and not some homegrown type name like uint8 - its in the standard since 1996!

Answer 2

There are two cases: either the function is manipulating hardware registers etc directly. Then you must have volatile in the parameter. Or the function has nothing to do with hardware registers at all. Then it should not have volatile. There is no middle ground between those two cases.

Furthermore, calc((const uint8_t*)array, value); is just a bad, possibly buggy version of

const uint8_t* ptr = array;
calc(ptr, value);

The former form is bad, because the order of evaluation of function arguments is unspecified behavior. The compiler may chose to evaluate the left operand or the right operand first, and you cannot know or assume the order. Since accessing a volatile is a side-effect, your original code can give different results each time the program is built. This is especially problematic (and possibly dangerous) in real time embedded systems.

Therefore it is recommended practice to never access volatile variables inside expressions (see MISRA-C:2004 12.2).

Answer 3

That depends on what really can happen due to volatile -ness.

If the values in this array change during function execution and these changes should be noticed, let them be volatile .

If it doesn't matter, or if the "old" values are more important, omit the volatile .