Replace one of the examples of the aliasing rule

[randomPoison]

The existing example is too similar to the first one, since it also is demonstrating a dangling reference to a heap allocation after modifying the Vec. This new example demonstrates a different angle to the aliasing rule: That it prevents incorrect optimizations. This gives us a chance to bring up undefined behavior, since that can cause problems in much more subtle ways.

I'm not sure if this example is quite correct, though. I'm still trying to figure out why exactly this might get mis-compiled in C, but that subtlety may not matter for the purpose of showing the point of the aliasing rule.

[djmitche]

What is the basis for this assertion? I was under the impression that C assumed everything aliased and therefore could not re-order operations very aggressively.

[fw-immunant]

Pointers would need to be tagged with restrict to allow this reordering in C.

[randomPoison]

I've gone back and reworked the example to better demonstrate UB in the C version. The C version now uses the restrict keyword and demonstrates a change in behavior when optimizations are enabled. I have also included links to Godbolt so that it's easy to demonstrate this for students. Let me know if this seems like a better option.

[fw-immunant]

I don't think it makes sense to say that the Rust function would be miscompiled if not for the aliasing rule. If Rust semantics were different, it would change how Rust is optimized--in every language optimizations must be semantics-preserving.

We could say that the Rust rules enable more optimizations than C compilers can perform (in general, e.g. without restrict), which is true, but in my opinion not really the strongest reason behind why Rust does things this way.