From d966a7f819c1f85cbe024ce66f1e28604f9bd658 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Tue, 29 Sep 2020 09:48:26 +0200 Subject: [PATCH] pointers are complicated: clarify that this post is not about exploring the trade-off --- personal/_posts/2018-07-24-pointers-and-bytes.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/personal/_posts/2018-07-24-pointers-and-bytes.md b/personal/_posts/2018-07-24-pointers-and-bytes.md index 68a2cb0..f3c9133 100644 --- a/personal/_posts/2018-07-24-pointers-and-bytes.md +++ b/personal/_posts/2018-07-24-pointers-and-bytes.md @@ -32,13 +32,18 @@ int test() { } {% endhighlight %} It would be beneficial to be able to optimize the final read of `y[0]` to just return `42`. +C++ compilers regularly perform such optimizations as they are crucial for generating high-quality assembly.[^perf] The justification for this optimization is that writing to `x_ptr`, which points into `x`, cannot change `y`. +[^perf]: To be fair, the are *claimed* to be crucial for generating high-quality assembly. The claim sounds plausible to me, but unfortunately, I do not know of a systematic study exploring the performance benefits of undefined behavior such as this. + However, given how low-level a language C++ is, we can actually break this assumption by setting `i` to `y-x`. Since `&x[i]` is the same as `x+i`, this means we are actually writing `23` to `&y[0]`. Of course, that does not stop C++ compilers from doing these optimizations. -To allow this, the standard declares our code to have [undefined behavior]({% post_url 2017-07-14-undefined-behavior %}). +To allow this, the standard declares our code to have [undefined behavior]({% post_url 2017-07-14-undefined-behavior %}).[^0] + +[^0]: An argument could be made that compilers should just not do such optimizations to make the programming model simpler. This is a discussion worth having, but the point of this post is not to explore this trade-off, it is to explore the consequences of the choices made in C++. First of all, it is not allowed to perform pointer arithmetic (like `&x[i]` does) that goes [beyond either end of the array it started in](https://timsong-cpp.github.io/cppwp/n4140/expr.add#5). Our program violates this rule: `x[i]` is outside of `x`, so this is undefined behavior. -- 2.30.2