From: Ralf Jung Date: Wed, 25 Jul 2018 06:22:07 +0000 (+0200) Subject: C is not portable assembly X-Git-Url: https://git.ralfj.de/web.git/commitdiff_plain/42c30afade02e540fa11b019e0211018b77bebea C is not portable assembly --- 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.