Comment by lelanthran
6 hours ago
The "anything can happen" means that the compiler can simply silently refuse to emit the code does the access.
Documenting that the instructions to access will always be eliminated makes it easier to predict what will happen.
Can you unravel this further (for those of us who don’t know compilers)? I’ve always assumed access past the end of an array can’t always be detected in C, so I don’t see how those instructions could be eliminated.
For example, a dynamically linked library that takes in a pointer, and then writes to the 10 ints after it—whether or not this behavior is defined is determined after that library is compiled, right?
> I’ve always assumed access past the end of an array can’t always be detected in C, so I don’t see how those instructions could be eliminated.
"Can't always be detected" is jut a different way of saying "Can sometimes be detected".
Upon detection, I'd rather that the compiler still emit the instructions, not elide the code altogether.
Now the behavior of your compiler/runtime stack is dependent on the sophistication of your compiler or runtime relative to the particular code at issue + the specific information available statically or dynamically in the instance.
That does not seem like an improvement if your goal is predictable, consistent behavior.
I think the disconnect here is that you're operating on the assumptions built by using common architectures that have solved these problems in implementation specific forms, and you're used to those solutions.
But just because those forms are common, doesn't mean the behavior is actually defined.
Ex - I might be using a vendor specific compiler for custom embedded devices where dynamic linking isn't available at all, and which might have complicated storage mechanisms that look nothing like standard memory pages.
I’m not sure there’s a disconnect at all (note that I’m not saagarjah, they and lelanthran seem to be pushing back on each other’s opinions; I’m just asking a clarifying question).
1 reply →