this post was submitted on 19 Mar 2024
145 points (92.9% liked)

Programming

17432 readers
212 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
 

Python is memory safe? Can't you access/address memory with C bindings?

you are viewing a single comment's thread
view the rest of the comments
[–] Dark_Arc@social.packetloss.gg 108 points 8 months ago (3 children)

Python is memory safe? Can't you access/address memory with C bindings?

You can do that in basically any language. Rust even has the ability to break out of its safeguards and write unsafe Rust code.

"Memory safety" in this context is more about the defaults and how easy it is to write unsafe code accidentally.

[–] GroteStreet@aussie.zone 32 points 8 months ago

Obligatory link to the Rustonomicon.

Should you wish a long and happy career of writing Rust programs, you should turn back now and forget you ever saw this book.

[–] Traister101@lemmy.today 31 points 8 months ago (2 children)

Unsafe Rust really just let's you play with pointers

This is the entirety of what Unsafe Rust allows

  • Dereference a raw pointer
  • Call an unsafe function or method
  • Access or modify a mutable static variable
  • Implement an unsafe trait
  • Access fields of unions
[–] declination@programming.dev 17 points 8 months ago* (last edited 8 months ago) (3 children)

I'm still onboard with rust as being better than C, however...

My understanding is that it is considerably harder to correctly write unsafe rust than it is to correctly write c, because if you accidentally violate any of safe rust's guaranteed invariants in an unsafe block, things go bananas.

[–] BatmanAoD@programming.dev 22 points 8 months ago

That's true in C as well, though. This is what people mean when they say things like "undefined behavior can result in time travel".

The difference is twofold:

  • Rust's rules for valid unsafe code are not completely formalized yet. This means that there are open questions about whether particularly complex patterns in unsafe code will be guaranteed by future versions of the compiler to be sound. Conversely, the C and C++ spec are generally sufficient to determine whether any particular piece of code has undefined behavior, even if actually analyzing it to find out is not possible automatically using existing static analysis tools.
  • Because safe Rust is so strict about what it permits, the compiler is able to make more aggressive optimizations; in theory, this could indeed cause undefined behavior to be "worse" at runtime than a comparable situation in a globally-unsafe language. I'm unaware of any actual examples of that phenomenon, though.
[–] Traister101@lemmy.today 9 points 8 months ago* (last edited 8 months ago) (2 children)

Yes Rust is harder to write than C, that's basically by design as it's due to the statically guaranteed memory safety. That's pretty magical. C doesn't have that and neither does C++ even with smart pointers and such. Rusts unsafe keyword is poorly named, what it actually does is tell the compiler that you the programmer guarantee Rusts rules are upheld within the unsafe block.

For example

Access or modify a mutable static variable

That is a global, that's incredibly hard to impossible to statically prove it's safely done, so you have to do it in an unsafe block. So you violating Rusts rules within an unsafe block is actually using the unsafe block wrong. That's not what it's for

[–] Solemarc@lemmy.world 2 points 8 months ago* (last edited 8 months ago)

I remember watching a video of someone writing C code and making the same thing in unsafe rust. While the C code worked just fine the rust code had UB in it and was compiled to a different set of instructions.

Unsafe rust expects you to uphold the same guarantees that normal rust does and so the compiler will make all the same optimisations it would if the code wasn't unsafe and this caused UB in the example rust code when optimised for performance. It worked just fine on the debug build, but that's UB for you.

[–] Fal@yiffit.net -1 points 8 months ago (2 children)

Yes Rust is harder to write than C

I would totally argue with this. Rust is way easier to write than C

[–] Traister101@lemmy.today 2 points 8 months ago (2 children)

I'd probably say it depends but I'm no Rust expert and I have no direct experience with C (though quite familiar with C++).

Basically I'd expect writing C to be easy, but not safe. IE you can quickly and easily write C that compiles but has runtime issues. Rust for the most part will catch everything but logic issues during/before compilation meaning once the program runs you'll have very high confidence in it's runtime behavior leading to time spent "fighting the compiler" instead of figuring out wtf is going wrong at runtime.

[–] Traister101@lemmy.today 2 points 8 months ago

I think primarily I don't really care to argue about if it's harder to write or not since it doesn't really matter. I think the pros Rust provides are worth all it's cons

[–] Fal@yiffit.net -2 points 8 months ago

IE you can quickly and easily write C that compiles but has runtime issues.

So what's "easy" about it then? Just getting something to compile? That's not a very good measure of "easyness".

[–] vext01@lemmy.sdf.org 2 points 8 months ago (1 children)

I agree for the most part, but writing data structures with shared mutable state can be a total pain in Rust.

[–] Fal@yiffit.net -1 points 8 months ago (1 children)

How so? That's like, the thing that makes rust awesome to write.

[–] vext01@lemmy.sdf.org 1 points 8 months ago (1 children)

It's hard to get those kinds of data structures through the borrow checker.

Try writing a doubly linked list.

[–] Fal@yiffit.net -3 points 8 months ago (1 children)

It's because it's hard to make them correct. It's not any harder to write it in rust than in C. Just C lets you do it wrong

[–] vext01@lemmy.sdf.org 1 points 8 months ago (1 children)

That's not right.

Try and write a mutable doubly linked list in Rust and you will find that it's problematic for the borrow checker.

Search online and you will find solutions that work around this using 'RefCell' (to delegate mutable borrows to runtime), or raw pointers with 'unsafe'.

[–] calcopiritus@lemmy.world 0 points 7 months ago (1 children)

Both RefCell and unsafe are features of the language. That's like saying python's OOP sucks if you don't use the class keyword.

[–] vext01@lemmy.sdf.org 1 points 7 months ago

I'm not saying it sucks. I'm saying it can be less straight-forward than conventional languages, even for experienced programmers.

The borrow checker is fantastic, but there's no doubt that it requires a new way of thinking if you've never seen Rust before.

[–] hunger@programming.dev 8 points 8 months ago

That depends a lot on how you define "correct C".

It is harder to write rust code than C code that the compiler will accept. It is IMHO easier to write rust code than to write correct C code, in the sense it only uses well defined constructs defined in the C standard.

The difference is that the rust compiler is much stricter, so you need to know a lot about details in the memory model, etc. to get your code past the compiler. In C you need the same knowledge to debug the program later.

[–] Dark_Arc@social.packetloss.gg 4 points 8 months ago (2 children)

And what does that exclude that C or C++ has that's memory unsafe? I suppose use after free?

Dereference a pointer without a bounds check is the major problem when we're talking about memory safety.

Accessing a union that's in an invalid state is also a big problem.

Use after free... Maybe?

Thread safe code isn't the issue otherwise Java, Python, etc would all be on the list of languages to run from.

Point being, that is still a very dangerous subset. Off-by one errors have done in a lot of C code (and C++ code that isn't using range-based loops).

A lot of these issues can be avoided in C++ by just using existing types like std::variant, std::unique_ptr, std::shared_ptr, std::array, and std::vector (with the at based accessor) instead of lower level constructs.

[–] Traister101@lemmy.today 6 points 8 months ago* (last edited 8 months ago) (1 children)

What Rust provides is statically guaranteed memory safety. Some C++ types will prevent memory issues however the language itself is unsafe. Playing with raw pointers is just as valid as using std::unique_ptr. In Rust however you must sign a contact (using unsafe) in order to play with raw pointers. Unsafe is you the programmer promising that you followed the rules. This is like how C++ says it's illegal to write UB and your program will break (and it's your fault) but enforced through a special type of block

[–] Dark_Arc@social.packetloss.gg 7 points 8 months ago (1 children)

In Rust however you must sign a contact (using unsafe) in order to play with raw pointers. Unsafe is you the programmer promising that you followed the rules. This is like how C++ says it's illegal to write UB and your program will break (and it's your fault) but enforced through a special type of block

Which is what I said, this is about the default.

My issue is not that I don't understand Rust provides static guarantees. My issue is that you raised a comparison between unsafe Rust and C++ code. In that comparison, you're basically saying "writing an entire program in a rust unsafe block would be better than writing an entire program in C++" and I think that is very wrong.

Rust unsafe is not better than normal C++ while following best practices for maintaining memory safety.

[–] arendjr@programming.dev 4 points 8 months ago

I wouldn’t be so sure myself. Even unsafe Rust still uses the borrow checker, for instance. And you still get stricter checks around overflows and such as well. What unsafe does is that it unlocks the ability to use raw pointers and call other unsafe functions (among a few other things), but importantly it doesn’t disable the safety features that Rust has built-in. While unsafe Rust does indeed have some gotchas on its own, I think in general you’re still better off even with unsafe Rust than with C++.

[–] arendjr@programming.dev 5 points 8 months ago* (last edited 8 months ago)

I would still like to take a moment to answer your specific questions more directly:

And what does that exclude that C or C++ has that’s memory unsafe? I suppose use after free?

I think indeed use after free is the main one, although data races are another. Both are prevented in Rust by the borrow checker.

Dereference a pointer without a bounds check is the major problem when we’re talking about memory safety.

I think that's only half of the issue, with the other half indeed being use after free. After all, using a reference isn't much different from dereferencing a pointer. But doing bounds check on all your pointers is relatively easy to do by humans; you see where the pointer is being used and you see if there's a check or not. But proving liveness of your references before you use them is much harder, because it often requires whole-program analysis to understand when the target may be destroyed. And in terms of danger, use after free is just as dangerous as unbound pointer access.

Thread safe code isn’t the issue otherwise Java, Python, etc would all be on the list of languages to run from.

Thread safe code is also the issue. The reason people don't have to run from Java is because data races there don't escalate to memory unsafety; they're just caught as "ordinary" exceptions and thus manifest as ordinary (but still hard-to-debug) bugs. But in C++ those too can create invalid memory accesses, with a possibility for exploitation. In fact, even Go has a memory unsafe data race in its threading model that occurs because of its use of fat pointers that embed both a data type and an address.

Point being, that is still a very dangerous subset. Off-by one errors have done in a lot of C code (and C++ code that isn’t using range-based loops).

It is indeed a dangerous subset, but as I mentioned elsewhere, Rust's borrow-checker, which prevents use after free with references is still active, even in unsafe code. Off-by-one errors are still bound-checked even in unsafe code, unless you explicitly use the non-bound-checked versions. Any Rust code that is valid safe Rust is just as safe when wrapped in an unsafe block. It is only when you explicitly use the unsafe features that you're on your own when it comes to safety.

A lot of these issues can be avoided in C++ by just using existing types like std::variant, std::unique_ptr, std::shared_ptr, std::array, and std::vector (with the at based accessor) instead of lower level constructs.

They indeed avoid some of the issues, but notably don't protect against use after free at all. And take std::vector as an example:

std::vector v;
v[2]; // out-of-bounds access

vs.

unsafe {
    let v = Vec::new();
    v[2]; // panic
}

Even wrapped in unsafe, the Rust equivalents are still safer.