4 ms·

To understand unsafe code you need to understand what's safe code and pointers first. Basically, safe code is automatically managed to get rid of memory leaks

To understand unsafe code you need to understand what's safe code and pointers first. Basically, safe code is automatically managed to get rid of memory leaks [0], dangling pointers [1], null pointer dereferencing [2], race conditions [3], and many other memory management bugs. You don't encounter any of these in JavaScript because it's a managed language, meaning there's a garbage collector [4] that looks after all your memory allocations. Contrary to the managed languages, C & C++ are unsafe and "native" (meaning that they're very close to the hardware level) - it's a wild land where you manage memory manually yourself. If you miss a single deallocation, you're left with a memory leak. If you deallocate a memory region twice, you have a double free situation [5]. So you have to be very cautious when writing code in C & C++. There are many techniques to make it easier (e.g. smart pointers [6]), but not all developers use them. Rust takes the middle ground: it combines safety with unsafety by using a know-how affine type system with a borrow checker, which allows values/variables to have only one owner. This system has properties of both managed and unmanaged code. "Unsafe" code in the context of Rust means that you consciously turn off the borrow checker, leaving on your own and managing memory deallocations manually, as in C. That makes it possible to interface your Rust code with the native code, at the cost of making you prone to all errors and bugs that are listed above. So it's a good thing to minimize usage of unsafe code, to allow the Rust compiler to check your code for safety. [0] https://en.wikipedia.org/wiki/Memory_leak https://en.wikipedia.org/wiki/Memory_leak [1] https://en.wikipedia.org/wiki/Dangling_pointer https://en.wikipedia.org/wiki/Dangling_pointer [2] https://en.wikipedia.org/wiki/Null_pointer#Dereferencing https://en.wikipedia.org/wiki/Null_pointer#Dereferencing [3] https://en.wikipedia.org/wiki/Race_condition https://en.wikipedia.org/wiki/Race_condition [4] https://en.wikipedia.org/wiki/Garbage_collection_(computer_science) https://en.wikipedia.org/wiki/Garbage_collection_(computer_s... [5] http://stackoverflow.com/questions/21057393/what-does-double-free-mean http://stackoverflow.com/questions/21057393/what-does-double... [6] https://en.wikipedia.org/wiki/Smart_pointer https://en.wikipedia.org/wiki/Smart_pointer

easytiger 11y ago
> . So you have to be very cautious when writing code in C & C++. There are many techniques to make it easier (e.g. smart pointers [6]), but not all developers use them. Not everyone has security as a requirement. Some people jsut want to write something that is both fast, predicable. Most banks don't make any security demands of internal applications because they are not accessible to the internet. At which point safety is just a way to slow you do.
- humanrebar 11y ago
  On the other hand, banks want numbers that actually add up properly, at least in the code that deals with money. If you use undefined behavior in C or C++, the languages do not guarantee that your bank account balances won't all be rounded down to the nearest prime number on Thursdays in odd numbered months in leap years.
- smtddr 11y ago
  >>Most banks don't make any security demands of internal applications because they are not accessible to the internet. At which point safety is just a way to slow you do. This is a bad way of doing things. That means as soon as someone finds a way to get inside the network, the bank is wrecked. You need to look at security from the point of assuming the attacker somehow got inside because it'll happen one day. http://digg.com/2015/ashley-madison-hack http://digg.com/2015/ashley-madison-hack """ MOTHERBOARD: How did you hack Avid Life Media? Was it hard? The Impact Team: We worked hard to make fully undetectable attack, then got in and found nothing to bypass. MOTHERBOARD: What was their security like? The Impact Team: Bad. Nobody was watching. No security. Only thing was segmented network. You could use Pass1234 from the internet to VPN to root on all servers. """
- jerven 11y ago
  Safe, also means that the application does not crash in funny ways with segmentation faults. Which is something that banks like a lot.
- cjcole 11y ago
  "Some people jsut want to write something that is both fast, predicable." And debuggable? Not crashing in random places due to stack or heap corruption helps there.
- lucozade 11y ago
  Let me know which banks you've worked at with this attitude. I just want to check I have no accounts with them. This most definitely is not the view taken at the financial companies I've worked in/with including a number of banks. They take internal security very seriously. There's the obvious threat of some form of break-in (no-one I know seriously believes that an unbreachable connected system is buildable). But there's also the issues of insiders taking stuff, Chinese walls and regulatory restrictions on access. It simply doesn't make economic sense to take security lightly any more.
ant6n 11y ago
How does it relate to writing C++11 without using raw pointers. I.e. using uniq_ptr (single owner), shared_ptr (multiple owners), references (not-an-owner). Are there benefits beyond that; and does it have the capabilities C++ has regarding making classes, operator overloading; templates?
- steveklabnik 11y ago
  > How does it relate to writing C++11 without using raw pointers. Rust's safety features are similar to those, but even stronger in a number of ways. There's two aspects to this: 1. more guarantees. You can write code with uniq_ptr that segfaults, but you cannot with Box<T>. 2. safety allows for patterns that would be dangerous in C++. For example, shared_ptr uses atomics for thread safety. Rust has two variants, Arc<T> with similar atomics, and Rc<T> without. If you're not using multiple threads, you can use Rc<T>, safe in knowing that Rust will give you a compile-time error if you introduce multithreading. In other words, there are ways that you need to be defensive in C++ that you do not in Rust. > does it have the capabilities C++ has regarding making classes, Rust does not really have OOP, exactly, we have structs and traits (concepts). One major difference is that we don't currently have inheritance, though proposals are being worked on. But since we already have the concept equivalent, we have extra power there. Tradeoffs. > operator overloading Rust lets you overload certain pre-defined operators, but not create new ones. > templates? AST based, hygenic macros, instead.
  - cristicbz 11y ago
    > AST based, hygenic macros, instead. Well and generics & traits. 99% of the places where C++ programmers use templates, they would use generics in Rust. `template std::vector<T>` <-> `Vec<T>` etc. It's only the niche metaprogramming ability of C++'s templates that would be replaced with macros.
    - steveklabnik 11y ago
      Yes, thanks, that's a more complete answer.
- 11y ago

easytiger 11y ago

> . So you have to be very cautious when writing code in C & C++. There are many techniques to make it easier (e.g. smart pointers [6]), but not all developers use them. Not everyone has security as a requirement. Some people jsut want to write something that is both fast, predicable. Most banks don't make any security demands of internal applications because they are not accessible to the internet. At which point safety is just a way to slow you do.

humanrebar 11y ago
On the other hand, banks want numbers that actually add up properly, at least in the code that deals with money. If you use undefined behavior in C or C++, the languages do not guarantee that your bank account balances won't all be rounded down to the nearest prime number on Thursdays in odd numbered months in leap years.
smtddr 11y ago
>>Most banks don't make any security demands of internal applications because they are not accessible to the internet. At which point safety is just a way to slow you do. This is a bad way of doing things. That means as soon as someone finds a way to get inside the network, the bank is wrecked. You need to look at security from the point of assuming the attacker somehow got inside because it'll happen one day. http://digg.com/2015/ashley-madison-hack http://digg.com/2015/ashley-madison-hack """ MOTHERBOARD: How did you hack Avid Life Media? Was it hard? The Impact Team: We worked hard to make fully undetectable attack, then got in and found nothing to bypass. MOTHERBOARD: What was their security like? The Impact Team: Bad. Nobody was watching. No security. Only thing was segmented network. You could use Pass1234 from the internet to VPN to root on all servers. """
jerven 11y ago
Safe, also means that the application does not crash in funny ways with segmentation faults. Which is something that banks like a lot.
cjcole 11y ago
"Some people jsut want to write something that is both fast, predicable." And debuggable? Not crashing in random places due to stack or heap corruption helps there.
lucozade 11y ago
Let me know which banks you've worked at with this attitude. I just want to check I have no accounts with them. This most definitely is not the view taken at the financial companies I've worked in/with including a number of banks. They take internal security very seriously. There's the obvious threat of some form of break-in (no-one I know seriously believes that an unbreachable connected system is buildable). But there's also the issues of insiders taking stuff, Chinese walls and regulatory restrictions on access. It simply doesn't make economic sense to take security lightly any more.

ant6n 11y ago

How does it relate to writing C++11 without using raw pointers. I.e. using uniq_ptr (single owner), shared_ptr (multiple owners), references (not-an-owner). Are there benefits beyond that; and does it have the capabilities C++ has regarding making classes, operator overloading; templates?

steveklabnik 11y ago
> How does it relate to writing C++11 without using raw pointers. Rust's safety features are similar to those, but even stronger in a number of ways. There's two aspects to this: 1. more guarantees. You can write code with uniq_ptr that segfaults, but you cannot with Box<T>. 2. safety allows for patterns that would be dangerous in C++. For example, shared_ptr uses atomics for thread safety. Rust has two variants, Arc<T> with similar atomics, and Rc<T> without. If you're not using multiple threads, you can use Rc<T>, safe in knowing that Rust will give you a compile-time error if you introduce multithreading. In other words, there are ways that you need to be defensive in C++ that you do not in Rust. > does it have the capabilities C++ has regarding making classes, Rust does not really have OOP, exactly, we have structs and traits (concepts). One major difference is that we don't currently have inheritance, though proposals are being worked on. But since we already have the concept equivalent, we have extra power there. Tradeoffs. > operator overloading Rust lets you overload certain pre-defined operators, but not create new ones. > templates? AST based, hygenic macros, instead.
- cristicbz 11y ago
  > AST based, hygenic macros, instead. Well and generics & traits. 99% of the places where C++ programmers use templates, they would use generics in Rust. `template std::vector<T>` <-> `Vec<T>` etc. It's only the niche metaprogramming ability of C++'s templates that would be replaced with macros.
  - steveklabnik 11y ago
    Yes, thanks, that's a more complete answer.
11y ago