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

Programming

17508 readers
8 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 [email protected]



founded 1 year ago
MODERATORS
145
submitted 8 months ago* (last edited 8 months ago) by [email protected] to c/programming
 

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
[–] [email protected] 4 points 8 months ago (4 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.

[–] [email protected] 6 points 8 months ago* (last edited 8 months ago) (2 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

[–] [email protected] 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 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++.

load more comments (1 replies)