3 ms·
Does this actually count as a side effect? I didn't think that dereferencing a variable could ever be the sole cause of a side effect. I thought that side effe
by Unklejoe 10y ago
Does this actually count as a side effect?
I didn't think that dereferencing a variable could ever be the sole cause of a side effect. I thought that side effects were only relevant in the context of a store (except for maybe volatile variables in which there are some ordering/barrier constraints applied as well). I realize that in practice, deferencing NULL can definitely cause a crash, but I don't know if it counts as a "side effect" in the typical "C" sense of the phrase.
I know that modifying the value of a variable which is accessed by means of a reference passed as an argument could definitely have side effects (since another unrelated function might read that data) and thus a store can’t be completely optimized away (but still can be reordered), but I don’t see why “dead” can’t be optimized away in this case.
In this case “dead” is a local variable, thus it can never be accessed by anyone outside of the function. Therefore, if there are no reads of the variable after that single store, I don’t see why the store can’t be completely eliminated.
In fact, this is a common issue when dealing with microcontrollers where configuration registers are sometimes written by assigning a value to a dereferenced address constant. That's why they get casted as volatile.
- jschwartzi 10y agoIf your dereference compiles into a read from a register, then in the case that the register is clear-on-read like some interrupt status registers I've seen, the dereference will have unintended side effects.
- Unklejoe 10y agoAgreed. However, I believe that in C, standard variable types are assumed to not have such side effects on a read, which is why such variables must be explicitly declared as "volatile".