From e032c1fbd09a504e6881e87ec6d0c17c8c7c9f9e Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Wed, 25 Jul 2018 08:22:07 +0200 Subject: [PATCH] C is not portable assembly --- personal/_posts/2018-07-24-pointers-and-bytes.md | 3 ++- 1 file changed, 2 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 c79cf61..adf82bd 100644 --- a/personal/_posts/2018-07-24-pointers-and-bytes.md +++ b/personal/_posts/2018-07-24-pointers-and-bytes.md @@ -19,7 +19,7 @@ I hope that by the end of this post, you will agree with me on both of these sta ## Pointers Are Complicated What is the problem with "pointers are just integers"? Let us consider the following example:
-(I am using C++ code here mostly because writing unsafe code is easier in C++, and unsafe code is where these problems really show up.) +(I am using C++ code here mostly because writing unsafe code is easier in C++, and unsafe code is where these problems really show up. C has all the same issues, as does unsafe Rust.) {% highlight c++ %} int test() { auto x = new int[8]; @@ -227,6 +227,7 @@ Using `Uninit` instead of an arbitrary bit pattern means miri can, in a single e ## Conclusion We have seen that in languages like C++ and Rust (unlike on real hardware), pointers can be different even when they point to the same address, and that a byte is more than just a number in `0..256`. +This is also why calling C "portable assembly" may have been appropriate in 1978, but is a dangerously misleading statement nowadays. With this, I think we are ready to look at a first draft of my "2018 memory model" (working title ;) -- in the next post. :) Thanks to @rkruppe and @nagisa for help in finding arguments for why `Uninit` is needed. -- 2.30.2