3 ms·

Sure you are. You are relying on the fact that bar is not allowed to take the address of an arbitrary object on the stack, perform some arithmetic on it, and me

Sure you are. You are relying on the fact that bar is not allowed to take the address of an arbitrary object on the stack, perform some arithmetic on it, and mess with the contents of the previous stack frame. This is not actually different reasoning than what you describe. I encourage you to try to formalize what you are saying. You'll find that it is remarkably hard to distinguish the two cases, especially if you understand the steps the compiler takes to get to these changes.

deleted 3y ago
[deleted]
kazinator 3y ago
It's very easy to distinguish the cases by division into "fraud" versus "accident". When optimizing, assume absence of fraud, but not accident. If, in the given language, it is dead easy for bar() to manipulate x by accident, and frequently occurs due to that being a pitfall in that language, then it would be stupid for the language to have advanced optimizations over local variables. Unless the implementors are confident that they can diagnose almost every instance of the pitfall.
- UncleMeat 3y ago
  > It's very easy to distinguish the cases by division into "fraud" versus "accident". When optimizing, assume absence of fraud, but not accident. I do not believe that this is true. If you can do it precisely, that'd be a significant contribution to the community. If you can it precisely in a way that doesn't create a massive overhead because of tracking object lifetimes explicitly then that'd be an incredible contribution to the community.