<story><title>“What the Hardware Does” Is Not What Your Program Does: Uninitialized Memory</title><url>https://www.ralfj.de/blog/2019/07/14/uninit.html</url></story><parent_chain><item><author>rkagerer</author><text>Would have liked to see the machine code generated by the example function, and a deeper dive mapping compiler choices to the unintuitive results.&lt;p&gt;The article (indeed the point of it) abstracts that all away behind &amp;quot;undefined behavior&amp;quot; and a mental model sitting between your code and its resulting executable.  Which is fine, but it leaves a loose end which fails to sate my curiosity.</text></item></parent_chain><comment><author>archgoon</author><text>It depends on whether you generate using rustc 1.28 or rustc 1.36, and whether you&amp;#x27;re compiling with or without optimzations. This does not crash in unoptimized rust (either 1.36 or 1.28) but it will crash in optimized rust 1.36.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;8Yxl2c&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;8Yxl2c&lt;/a&gt;&lt;p&gt;I think though (as your question indicates); that the author misses the point of why people care about &amp;quot;What the hardware does&amp;quot;. At the end of the day, assembly code is going to execute, and that assembly code is going to (despite the authors protestations to the contrary) have well defined memory of one value or another. The moment you start saying &amp;quot;Rust has a third value of uninitialized&amp;quot; the question comes up &amp;quot;How is that abstraction enforced by the hardware?&amp;quot; This is valuable information for understanding how the language works.&lt;p&gt;From the authors discussion, I was expecting some sort of sentinel value being checked; however, instead, the uninitialized memory access is detected by the compiler and it panics uniformly regardless of the actual memory state.&lt;p&gt;The idea that one should only worry about the abstract virtual machine of rust seems like an encouragement of magical thinking. &amp;quot;Don&amp;#x27;t worry about how any of this works, the compiler will just make it happen&amp;quot;. This will not go over well with many people who are curious about learning Rust.&lt;p&gt;However, if the author is arguing &amp;quot;Don&amp;#x27;t let the behavior of a naive enforcement of a Rust safety construct dictate how the optimized version should work&amp;quot; this seems like a more interesting position; but it&amp;#x27;s not clear that is the argument being made here.</text></comment>
<story><title>“What the Hardware Does” Is Not What Your Program Does: Uninitialized Memory</title><url>https://www.ralfj.de/blog/2019/07/14/uninit.html</url></story><parent_chain><item><author>rkagerer</author><text>Would have liked to see the machine code generated by the example function, and a deeper dive mapping compiler choices to the unintuitive results.&lt;p&gt;The article (indeed the point of it) abstracts that all away behind &amp;quot;undefined behavior&amp;quot; and a mental model sitting between your code and its resulting executable.  Which is fine, but it leaves a loose end which fails to sate my curiosity.</text></item></parent_chain><comment><author>Arnavion</author><text>The dropdown next to the &amp;quot;Run&amp;quot; button in the playground link shows you the ASM. But here&amp;#x27;s the relevant part:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    playground::main:
        push rax
        call std::panicking::begin_panic
        ud2
&lt;/code&gt;&lt;/pre&gt;
That is, it&amp;#x27;s an unconditional panic.</text></comment>