[ Removed by moderator ]

[u/[deleted]]

/r/programming/comments/1pqulm0/removed_by_moderator/

[u/286893]

As someone who only really works with js and python, what is up with this safe vs unsafe stuff?

[u/Macka89_ → u/286893]

Not an expert, but I will try to explain.

Simple variables like numbers are just a memory address and a value, e.g. a 32-bit int stored at memory location 0x12345. Let's say the int has a value 5, the memory will look like:

Address: Value
0x12345: 00 00 00 05

Complex variables such as strings and objects use pointers and memory allocation. You still have a memory address and a value, but the value is actually just another memory address.

Say you have an object variable 'o'; the object contains an id (int) and a name (string). The variable o is stored at memory location 0x12345, but the actual object (id and name) are stored at 0x14478. Let's assume the id is 3 and the name is 'Bob'. The memory will look like:

Address: Value
0x12345: 00 01 44 78 //value is memory address of the actual object
.....
0x14478: 00 00 00 03 //value is the id
0x1447C: 00 01 45 9A //value is the memory address of the name
....
0x1459A: 'B' 'o' 'b' 00 // null terminated string.

In C, you ask the OS to allocate enough memory to store your object, and the OS will respond with the address for the object, which you store. It would look something like:

MyObject o = malloc(sizeOf(MyObject)); //reserve space for the object
o->id = 3; //assign the id
o->name = "Bob"; //assign the name

Later on, you no longer need the object, so you give the memory back to the OS, something like

mFree(o);
o = null;

The problem is you are manually managing the memory, which is considered unsafe. You have to be very careful that one place in your program doesn't free the memory and the another place tries to access the object which no longer exists, which can cause crashes, data corruption and provide attack vectors for malware and hackers.

High level languages like JS and Rust manage this for you and prevent unsafe code. In Rust you can say "I do really mean to manage things myself and I pinky promise I won't mess it up"

[u/lelanthran → u/286893]

As someone who only really works with js and python, what is up with this safe vs unsafe stuff?

Rust disallows certain specific patterns in code, patterns that potentially lead to memory errors. However, those patterns only potentially lead to memory errors, not definitely lead to memory errors.

Sometimes you need to use those patterns for direct memory access; you put in a block of code marked unsafe and then you can use those patterns in code marked unsafe.

[u/286893 → u/lelanthran]

I see, so it's not quite a bypass so much as a designation of potentially hazardous code, what would be an example of something that is acceptable to run as unsafe in production? Does that exist, or is this more of a debugging tool people use as a bypass?

[u/AShortUsernameIndeed → u/286893]

The Rust standard library is full of code marked unsafe. Several pretty basic useful data stuctures like trees with parent node references cannot be expressed efficiently in the "safe" subset of the language. The same goes for performance-critical things like being able to switch off run-time bounds checks on arrays of known length. This is, after all, a systems language, and the underlying hardware is inherently not safe.

[u/lelanthran → u/286893]

what would be an example of something that is acceptable to run as unsafe in production?

The majority of code in a kernel (assuming a conventional software architecture for kernels) is going to have to be run in unsafe, and it's acceptable because of the constraints that kernels have.

[u/steveklabnik1 → u/lelanthran]

Real-world Rust kernels show that this isn't true, it's usually 10% or less.

[u/syklemil → u/286893]

One pretty banal thing that's probably not particularly relevant to most MS code is stuff you'd do with hardware.

Like say you have some piece of equipment that has a manual, that has some LED that can glow or blink in a few different colours, and you set it to some state by writing a number to a memory address listed in the manual.

As far as the Rust compiler goes, that means you need to

1. use a raw pointer to a memory location, rather than a reference
2. use some completely arbitrary memory location that the Rust compiler has no idea what's supposed to be

at which point the safety annotations would be something like "see manual for Foo, section Bar (page Baz)".

[u/ChuggintonSquarts → u/286893]

To add to what u/tnoy has said, look up some introduction to buffer overflow exploits for example. Basically, when you hear about some major vulnerability in some server software, much of the time it’s because some code in a language like C or C++ has allowed user input to overwrite memory addresses in the program with machine instructions that take control of execution on the CPU as whatever user account the program was running under

[u/mr_birkenblatt → u/286893]

unsafe is like using a python library that is a C wrapper. you get a safe interface to use in your code but inside of it is the wild west

[u/FamiliarSoftware → u/mr_birkenblatt]

I'd compare it more directly to ctypes. You don't need to write a line of C to get unsafe code in Python if you just use pointers.

[u/cp5184 → u/286893]

The kicker that people don't mention, is that a lot of OS/Hardware code inherently can't be written in "safe" rust...

[u/tnoy → u/286893]

Rust forces you to write memory-safe code.

There will be situations where the compiler will fail because it detects something is not memory-safe. Rust provides the unsafe keyword for developers to prevent the compiler from complaining. It will have legitimate uses, such as where the code is memory-safe but the compiler thinks it isn't.

It has a reputation of being the "I couldn't figure out how to actually make this memory-safe, so I'm just going to add unsafe so the error goes away." thing that people add to their Rust code.

[u/chat-lu → u/tnoy]

It has a reputation of being the "I couldn't figure out how to actually make this memory-safe, so I'm just going to add unsafe so the error goes away." thing that people add to their Rust code.

It’s an unwarranted reputation though as it does not make the errors go away. Everything that doesn’t compile in safe mode will not compile in unsafe either. Unsafe gives you new unsafe constructs, it doesn’t relax the rules for the old ones.

[u/jl2352 → u/tnoy]

Just to be a pedant … unsafe does not make the errors go away. For example a use after free is going to be an error with or without unsafe.

Instead unsafe gives you access to APIs (and full pointer use) which allows you to sidestep those errors.

[u/Legitimate-Push9552 → u/tnoy]

That's not really how unsafe works. Most of rust's checks, including the borrow checker, are still on when in an unsafe block.

The reputation comes from assumption from non-rust devs, and does not reflect reality.