add forum link
authorRalf Jung <post@ralfj.de>
Sun, 14 Jul 2019 16:35:58 +0000 (18:35 +0200)
committerRalf Jung <post@ralfj.de>
Sun, 14 Jul 2019 16:35:58 +0000 (18:35 +0200)
ralf/_posts/2019-07-14-uninit.md

index f454bfd..702ac47 100644 (file)
@@ -1,6 +1,7 @@
 ---
 title: '"What The Hardware Does" is not What Your Program Does: Uninitialized Memory'
 categories: rust
+forum: https://internals.rust-lang.org/t/what-the-hardware-does-is-not-what-your-program-does-uninitialized-memory/10561
 ---
 
 This post is about uninitialized memory, but also about the semantics of highly optimized "low-level" languages in general.
@@ -113,4 +114,6 @@ I hope C/C++ will come around to do the same, and there is some [great work in t
 If you want to do me a favor, please spread the word!
 I am trying hard to combat the myth of "what the hardware does" in Rust discussions whenever I see it, but I obviously don't see all the discussions---so the next time you see such an argument, no matter whether it is about uninitialized memory or [concurrency](http://hboehm.info/boehm-hotpar11.pdf) or [out-of-bounds memory accesses](https://github.com/rust-lang/rust/issues/32976#issuecomment-446775360) or anything else, please help by steering the discussion towards "what the Rust abstract machine does", and how we can design and adjust the Rust abstract machine in a way that it is most useful for programmers and optimizing compilers alike.
 
+As usual, if you have any comments, suggestions or questions, [let me know in the forums](https://internals.rust-lang.org/t/what-the-hardware-does-is-not-what-your-program-does-uninitialized-memory/10561).
+
 #### Footnotes