3 ms·
In C/C++, out-of-bounds memory access is in undefined behavior, so the compiler can assume it is a nop, so it is dead code and eliminate it. In go, out-of-boun
by kevhito 10y ago
In C/C++, out-of-bounds memory access is in undefined behavior, so the compiler can assume it is a nop, so it is dead code and eliminate it.
In go, out-of-bounds array/slice access is equivalent to calling panic. So
_ = a[i]
isn't dead code unless you can be sure that a[i] is in bounds. So yes, I imagine BCE should come before dead code elimination.
- e3b0c 10y agoI don't think bounds checking can be done at compile-time, especially in C/C++.
- XMPPwocky 10y agoNot in the general case. char x[4]; printf("%c", x[4]); That's pretty easy to detect.
- ithkuil 10y agohere you're talking about compile time bound check _elimination_, i.e. statically determine when you can remove a runtime bound check which would have been added by the compiler. I think e3b0c was talking about completely static bound checks.
- codys 10y agoNo. We can look at the example given above and clearly know/prove that the access is out of bounds. ie: a C compiler could emit a diagnostic (or decide it's undefined behavior and treat it as unreachable). There aren't any bounds checks above to eliminate.
- deleted 10y ago[deleted]
- IshKebab 10y agoI think he means that the result isn't used.
- nothrabannosir 10y agoYes, but that doesn't matter: array indexing is not a "pure" function because it can panic. That's why you can't optimise it away, even if the result isn't used.
- IshKebab 10y agoAh I see.