{"id":3747,"date":"2018-07-23T11:05:23","date_gmt":"2018-07-23T09:05:23","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=3747"},"modified":"2023-08-06T21:49:51","modified_gmt":"2023-08-06T19:49:51","slug":"rust-safety-during-and-after-programming","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2018\/07\/23\/rust-safety-during-and-after-programming\/","title":{"rendered":"RUST – Safety During and After Programming"},"content":{"rendered":"

Intro<\/h4>\n

The programming language Rust is dwelling on the web for half a decade already. Initially started as a personal project by an Mozilla employee and later continued by the Mozilla Foundation itself, it repeatedly gained attention with the claims of being the language of choice for technically safe software \u2013 including system software.<\/p>\n

With this blog entry I want to give you an introduction to the language and talk about how said safety has been proven mathematically.<\/p>\n

By the way, if you want to try out some code snippets from this blog post, you can do so directly online here: https:\/\/play.rust-lang.org\/<\/a>
\n
\n <\/p>\n

The Basics<\/h4>\n

Rust is a fully compiled language with a Syntax fairly similar to C.
\nThe basic language is procedural and the variable scopes are within curly brackets ( \u2018{}\u2019 ).<\/p>\n

A first significant difference is the variable initialization with the keyword let<\/strong> and optional implied variable type. A very simple program looks as follows (Note, the code-blocks say “C\/C++” because Rust is sadly not available here >: ):<\/p>\n

fn main() {\n   let on_world = true;\n    \n   if on_world \n    {println!(\"Hello World!\");}\n   else\n    {println!(\"Goodbye, World.\");}\n}<\/pre>\n
It has the output \u201cHello World\u201d.<\/p>\n
To choose the variable type explicitly, the first line would need to look as follows:<\/p>\n
let on_world : bool = true;<\/pre>\n
So far so good and unsurprising.
\nThings turn more interesting in the following example:<\/p>\n
let s1 = String::from(\"Hello\");\nlet s2 = s1;\nprintln!(\"{}, world!\", s2);\nprintln!(\"{}, world!\", s1);<\/pre>\n
ERROR: -> Value used here after MOVE<\/em><\/strong><\/p>\n
This error occurs because Rust MOVES<\/strong> the content of non-primitive variables by default instead of copying them. That simply means that the String \u201cHello\u201d is in variable s2<\/strong> and not anymore in s1 <\/strong>which has been invalidated automatically.
\nIf you do want to COPY<\/strong> the content, you must explicitly write:<\/p>\n
let s2 = s1.clone();<\/pre>\n
The following is just another variant of the same aspect but shows a different way of avoiding the error:<\/p>\n
let s1 = String::from(\"Hello\");\ntoWorld( &s1 );\nprintln!(\"{}, world!\", s1);<\/pre>\n
 <\/p>\n
toWorld<\/strong> is a function here which takes a single argument of the String type.
\nNote the \u2018&<\/strong>\u2019 symbol for the variable. Without it, we would have the same error as before \u2013 the println<\/strong> macro (behaves here like a function) would raise an error because s1 isn\u2019t anymore.<\/p>\n
However \u2018&<\/strong>\u2019 caused that only a reference has been given away, not the content of the variable itself.
\nThe result is that the outer scope can still use s1<\/strong> but the toWorld<\/strong> function would not be able to modify the variable.<\/p>\n
We will talk about the background and reason of this behavior later on.<\/p>\n
Let\u2019s stay at functions and look at a code snipped you might accidentally write similarly in C++ and thus end up in one of its infamous traps:<\/p>\n
fn main()\n{\n   let reference_to_nothing = dangle();\n}\nfn dangle() -> &String\n{\n   let s = String::from(\"Hello\");\n   return &s;\n}<\/pre>\n
ERROR: -> <\/em><\/strong>no value to BORROW from<\/em><\/strong><\/p>\n
The function dangle<\/strong> \u00eds defined to have the return type \u201creference to String<\/strong>\u201d.
\nHowever while C++ would allow you to return this reference of the object that has been created inside the function, Rust throws an error at compiletime.<\/p>\n
The reason is that objects are automatically destroyed when they end out of their scope. That means after the function-call, s<\/strong> doesn\u2019t exist anymore.
\nFurthermore the compiler recognized that the variable would be empty and doesn\u2019t allow that.<\/p>\n
The result is that there are no dangling reference<\/strong>s in Rust and therefore no \u201cnull pointer\u201d or \u201caccess violation\u201d trouble!<\/p>\n
Now on to the last basic example I shall give you as it shows another unique feature of the language:<\/p>\n
let mut s = String::from(\"Hello\");\nlet rs = &mut s;\nrs.push(\u2018W\u2019); \/\/ pushes a letter into the string\ns.push(\u2018o\u2019); \/\/ pushes another letter<\/pre>\n
ERROR: -> <\/em><\/strong>cannot borrow \u2018s\u2019 as mutable more than once<\/strong><\/p>\n
So far, all variables \u2013 or maybe we should just call them \u2018objects\u2019 \u2013 we defined simply with \u2018let<\/em><\/strong>\u2019<\/strong>, were in fact what other languages would call constants. They were not changeable.<\/p>\n
Of course, usually we want variables which are\u2026 well, variable.<\/p>\n
That\u2019s where the \u2018mut<\/strong>\u2019 keyword comes into play and tells the compiler to allow us to change the value. However the upper code fails with said error nevertheless. The reason is that technically spoken, we have given the RIGHT<\/strong> to modify the variable to the variable \u201crs<\/strong>\u201d. As a result, \u2018s<\/strong>\u2019 does not have this right anymore and therefore may not modify the content.<\/p>\n
The reason for this initially cumbersome behavior is what the developers of Rust call the \u201cOwnership Concept<\/strong>\u201d.<\/p>\n
 <\/p>\n
The Ownership Concept<\/h4>\n
The roots of said constrictions can be summed up in three rules:<\/p>\n
    \n
  1. Each value has a variable that\u2019s called its \u201cowner\u201d<\/li>\n
  2. There can only be one owner for the value at a time<\/li>\n
  3. When the owner goes out of scope, the value will be dropped<\/li>\n<\/ol>\n
    The consequences are that no memory is accessible without \u201cowning\u201d it<\/strong> and there\u2019s no memory around which doesn\u2019t have an owner<\/strong> (except for inside \u2018unsafe blocks\u2019 about which we will talk  later).<\/p>\n
    This setup prevents several problems and has certain benefits:<\/p>\n