From f1e93146eae099784ef2a73000a04e579cf6f06f Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Sun, 14 Jul 2019 18:35:58 +0200 Subject: [PATCH 1/1] add forum link --- ralf/_posts/2019-07-14-uninit.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ralf/_posts/2019-07-14-uninit.md b/ralf/_posts/2019-07-14-uninit.md index f454bfd..702ac47 100644 --- a/ralf/_posts/2019-07-14-uninit.md +++ b/ralf/_posts/2019-07-14-uninit.md @@ -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 -- 2.30.2