We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
IU have a variable which can be chyanged outside the interrupt but inside the ISR it is only read. Its value don't change in it. Should it be volatile.
volatile is never needed for auto variables.
Errrm. never is a little too strong. It is possible for the address of that variable to be passed to something that is processed by an ISR.
Well, volatile isn't needed for auto variables. But a developer can manage to create aliasing to that variable by taking the address of it. But the question is if it should be seen as an "auto" variable when people accesses it using pointers. Aliasing, by the way, is one of the better known methods to create truly broken code.
But the question is if it should be seen as an "auto" variable when people accesses it using pointers
Yes.
You disappoint me. I have nothing further to say on the matter. Goodbye.
No, I don't think there's any question about that.
Whether a variable is automatic or not doesn't depend on how you use - or abuse - it.
Note that the function that gets a pointer to a variable will not be able to generate any code based on any "auto" optimization rules. From a code perspective, it will just be a pointer to memory - and the majority of processors don't have any special, magic, memory reserved for "auto" variables.
But the compilers do have sets of optimization rules that looks different, depending on what is known about a variable at the point of access. So the optimizers have different rule sets if they see a variable as auto, or global or indirectly accessed.
Unless the function call is inlined, the variable will no longer be seen as an auto variable - but the pointer to it will be - when the execution enters the receiving function.
volatile can also be useful on auto variables in functions that call setjmp