145
submitted 7 months ago* (last edited 7 months ago) by seth@lemmy.world to c/programming@programming.dev

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

top 50 comments
sorted by: hot top controversial new old
[-] Dark_Arc@social.packetloss.gg 110 points 7 months ago

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 7 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 7 months ago

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 7 months ago* (last edited 7 months ago)

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 7 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 10 points 7 months ago* (last edited 7 months ago)

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

load more comments (12 replies)
[-] hunger@programming.dev 8 points 7 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.

load more comments (5 replies)
[-] onlinepersona@programming.dev 57 points 7 months ago

Mr Stroustrup can spin it however he likes, but 70% of CVEs are caused by memory errors in unsafe languages like C and C++. That isn't happening because the majority of their devs are idiots. The language is the problem.

Talking about "but there are tools" and "hold on a minute, there a ways to write safe C++" is missing. It's way too easy to write memory unsafe code in C++. The opposite is true of other languages and that's why they are being recommended (dare I say pushed) over C++. To write memory unsafe Rust for example, you really, really have to want to.

C++ is his baby, Of course he won't acknowledge it and it was entirely predictable he would blame the programmers. The language will be the equivalent of COBOL in a decade or two.

CC BY-NC-SA 4.0

[-] Technus@lemmy.zip 36 points 7 months ago

If "just don't be an idiot" worked in the real world we wouldn't have any need for laws or safety regulations or certifications. It's not and never has been a compelling argument.

Writing C++ is like walking around a construction site without a hard hat and going "ah I don't need it, I'll just make sure nothing falls on my head." Yeah sure, buddy, we'll make sure that's written on your tombstone.

load more comments (3 replies)
[-] Feathercrown@lemmy.world 49 points 7 months ago* (last edited 7 months ago)

$100 says his response boils down to "just don't write unsafe code"

Edit: It did. He also said C++ is working to implement optional safety features, but tl;dr:

Of the billions of lines of C++, few completely follow modern guidelines

And the modern guidelines are mostly an unenforced list of things not to do.

[-] merthyr1831@lemmy.world 22 points 7 months ago

doesnt enforce memory safety damn all these stupid devs dont know how to write memory-safe code!!!

[-] porgamrer@programming.dev 19 points 7 months ago

Even following the guidelines, modern C++ is just a huge pile of half-finished ideas. It goes pretty well for the first few hundred lines of code, and then you hit a very basic problem where the solution is "yes this will work great in C++26, if the proposal doesn't get delayed again".

load more comments (3 replies)
[-] otl@apubtest2.srcbeat.com 8 points 7 months ago

$100 says his response boils down to "just don't write unsafe code"

Edit: It did. He also said C++ is working to implement optional safety features, but tl;dr:

Of the billions of lines of C++, few completely follow modern guidelines

Pretty sure this is a No true Scotsman moment. (I've always wanted to bring this fallacy up but I never knew when lol)

load more comments (1 replies)
[-] litchralee@sh.itjust.works 38 points 7 months ago

I'm not a Rust developer (yet), but I understand its strength in this regard as: Rust is statically memory safe by default, and code which isn't statically memory safe must be declared with the unsafe keyword. Whereas C++ has not deprecated C-style pointers, and so a C engineer can easily write unsafe C code that's valid in a C++ compiler, and no declaration of its unsafeness is readily apparent to trigger an audit.

It's nice and all that C++ pioneered a fair number of memory safety techniques like SBRM, but the debate now is about safety by default, not optional bolt-on safety. All agree that the overall process to achieve correct code is paramount, not just the language constructs.

[-] snowe@programming.dev 38 points 7 months ago

It's also just a huge fallacy. He's saying that people just choose to not write memory safe code, not that writing memory safe code in C/C++ is almost impossible. Just look at NASA's manual for writing safe C++ code. It's insanity. No one except them can write code that's safe and they've stripped out half the language to do so. No matter how hard you try, you're going to let memory bugs through with C/C++, while Rust and other memory safe languages have all but nullified a lot of that.

[-] MajorasMaskForever@lemmy.world 21 points 7 months ago* (last edited 7 months ago)

As someone who is in the aerospace industry and has dealt with safety critical code with NASA oversight, it's a little disingenuous to pin NASA's coding standards entirely on attempting to make things memory safe. It's part of it, yeah, but it's a very small part. There are a ton of other things that NASA is trying to protect for.

Plus, Rust doesn't solve the underlying problem that NASA is looking to prevent in banning the C++ standard library. Part of it is DO-178 compliance (or lack thereof) the other part is that dynamic memory has the potential to cause all sorts of problems on resource constrained embedded systems. Statically analyzing dynamic memory usage is virtually impossible, testing for it gets cost prohibitive real quick, it's just easier to blanket statement ban the STL.

Also, writing memory safe code honestly isn't that hard. It just requires a different approach to problem solving, that just like any other design pattern, once you learn and get used to it, is easy.

load more comments (4 replies)
[-] ryannathans@aussie.zone 9 points 7 months ago
[-] snowe@programming.dev 24 points 7 months ago* (last edited 7 months ago)
[-] solrize@lemmy.world 9 points 7 months ago

That first link is about a document from 2006, while C++ became a lot safer with C++11 in 2011. It's much easier to write safe C++ now, if you follow current guidelines:

https://isocpp.github.io/CppCoreGuidelines/

load more comments (5 replies)
load more comments (1 replies)
load more comments (3 replies)
[-] BehindTheBarrier@programming.dev 37 points 7 months ago

Why wait and hope for C++ to get where modern languages are now? I know there's value in the shared experience in C++ that if adapted would make it stronger, but I can only see a development of C++ having to force a drop of a lot of outdated stuff to even get started on being more suitable.

But the language is just not comfortable to me. From large amounts of anything creating undefined behavior, the god awful header files which I hate with a passion, tough error messages and such. I also met a fun collision of C++ in Visual Studio and using it with CMake in CLion.

I've just started looking at rust for fun, and outside not understanding all the errors messages with the bounded stuff yet, figuring out what type of string I should use or pass, and the slow climb up the skill curve, it's pretty nice. Installing stuff is as easy as copy pasting the name into the cargo file!

Rust is just the prospective replacement of C++ though, people act like the White house said that C++ should be replaced by rust now. But the just recommend it and other languages, C# will do for a lot of people that does not need the performance and detail that the aforementioned languages target. Python is targeting a whole different use, but often combined with the faster ones.

C++ will live a long time, and if the popularity dies down it will surely be very profitable to be a developer on the critical systems that use it many years from now. I just don't think an evolution of C++ is going to bring what the world needs, particularly because of the large amount of existing memory related security vulnerabilities. If things were good as they are now, this recommendation would not be made to begin with.

[-] arendjr@programming.dev 15 points 7 months ago

I totally agree with this comment, and on top of that I would recommend anyone who really cares about the current state of affairs regarding safety in C++ to read this overview: https://accu.org/journals/overload/32/179/teodorescu/

Quote:

Personally, I am not convinced that in the near future, C++ can do something to stop this trend. C++ will leak talent to other languages (currently Rust, but perhaps in the future to Cppfront, Carbon, Hylo or Swift). If the progress towards safety started in 2015 as Bjarne suggested, the last 8 years have seen very little progress in safety improvements. Even with accelerated efforts, the three-year release cycle and slow adoption of new standards will keep C++ a decade away from addressing major safety concerns.

[-] merthyr1831@lemmy.world 32 points 7 months ago

He can get mad all he likes but there's a reason the Linux kernel's experiment with rust is going much smoother than C++ (which only lasted a literal week btw)

[-] _dev_null@lemmy.zxcvn.xyz 28 points 7 months ago

Biden administration seems oblivious of the strengths of contemporary C++

Well ok, but the concern is about the weaknesses, Mr. Stroustrup.

load more comments (5 replies)
[-] cook_pass_babtridge@sh.itjust.works 14 points 7 months ago

I'd love to see Bjarne Stroustrup being grilled by Congress about this, and have to explain shared pointers and reference counting to the same people who didn't understand how Facebook made money.

[-] Rikj000@discuss.tchncs.de 12 points 7 months ago* (last edited 7 months ago)

TLDR: But-hurt C++ dev has a hard time accepting that his favorite language is not memory safe.

[-] Dark_Arc@social.packetloss.gg 15 points 7 months ago

C++ is leagues above C in this regard. He's rightly upset that they're lumping the two together.

Bjarne's work for safety profiles could indeed manifest in a solution that guarantees memory safety; time will tell. C++ is a moving target.

[-] marcos@lemmy.world 13 points 7 months ago

C++ is leagues above C in this regard.

It's really not. It has the same flaws, some libraries that promise to avoid them (as long as you don't hold them wrong - what every single programmer does), and lots and lots of new flaws that may come from anywhere.

load more comments (1 replies)
[-] hunger@programming.dev 9 points 7 months ago* (last edited 7 months ago)

That depends on how you decide which bucket something gets thrown into.

The C++ community values things like the RAII and other features that developers can use to prevent classes of bugs. When that is you yard-stick, then C and C++ are not in one bucket.

These papers are about memory safety guarantees and not much else. C and C++ are firmly in the same bucket according to this metric. So they get grouped together in these papers.

[-] WitchHazel@lemmygrad.ml 10 points 7 months ago

Sounds like he's just mad something he made is being replaced with something that is better in every conceivable way

Sorry bud but most people are focusing on rust, not python, and you've been lapped by them several times over.

load more comments (5 replies)
[-] signor@lemmy.world 7 points 7 months ago

So how fucked am I for starting to learn cpp as my first language, or is this a later down the road thing to worry about?

[-] thomask@lemmy.sdf.org 9 points 7 months ago

If you can write correct C++ you'll be able to write Rust code that compiles first time. Don't stress, you're learning the good stuff.

[-] lysdexic@programming.dev 8 points 7 months ago

So how fucked am I for starting to learn cpp as my first language, or is this a later down the road thing to worry about?

I don't see why you should be concerned, except that no professional software developer is limited to use one specific programming language.

Even if you pay attention to the disaster prophets in the crowd, which are mainly comprised of fanboys implicitly and explicitly promoting their pet language/frameworks, C++ dominates all aspects of the computing ecosystem, which means that in the very least the whole world needs to maintain existing C++ projects to continue to work. See COBOL for reference.

[-] otl@apubtest2.srcbeat.com 5 points 7 months ago

Ah that's an easy one - what would you like to do?

My first uh... "language" was bourne shell. Not because I thought it was a cool language, but because that's what let me do things I wanted to do at the time: automate heaps of Linux, BSD stuff.

There are heaps of libraries and applications where C++ is the choice e.g. video games. My friend is great at Javascript because he loves web browser tech.

Don't stress - have fun! :)

load more comments (2 replies)
[-] 0x0@programming.dev 7 points 7 months ago

The Rust lobby has reached the white house. In other news...

[-] words_number@programming.dev 5 points 7 months ago

Kinda sad how that guy destroys his reputation so late in his life. I mean he actually contributed a lot to the field of software development, but just refuses to accept that C++ days are thankfully over. The language has grown into a complete abomination, but all the experience we gained during its long history (good and bad) are extremely valuable for designing new languages from now on. One can't rescue a design by just adding things to it (regardless of the kind of design), that's just a simple truth. Thus, a backwards compatible C++ can never become even half as good as rust is already today (and there's of course always room for improvement). But that's not because bjarne did something stupid, but because humanity as a whole didn't know better back than. He could just accept that, embrace new technology, retire in dignity, be remembered as highly admired and appreciated. Instead he acts like a butthurt idiot, trying to defend that cars shouldn't have seatbelts, because if everyone drives carefully, nothing bad will happen anyway. Pathetic.

[-] mox@lemmy.sdf.org 21 points 7 months ago

One can’t rescue a design by just adding things to it (regardless of the kind of design), that’s just a simple truth.

This statement could also be applied to Perl, PHP, JavaScript, and most other languages that eventually add new ways of doing things, especially if they preserve backward compatibility. I'm not sure that this is a condemnation of C++ so much as an inevitable consequence of being successful for a long time.

To be clear, I'm not defending C++. Just pointing out that it's not unusual in this regard. I have no doubt that Rust will also have vestigial warts in time, if it doesn't already.

[-] superb@lemmy.blahaj.zone 8 points 7 months ago

Why can’t it be both a condemnation of C++ AND an inevitable consequence of success? C++ was a success, but we’ve learned a lot and it’s time to move on

[-] mox@lemmy.sdf.org 8 points 7 months ago

Condemning apples for having seeds doesn't make a reasonable case for choosing other fruit, which also have seeds.

load more comments (2 replies)
[-] Corbin@programming.dev 7 points 7 months ago

You are very close to a deep truth of language design: all large popular languages slowly die from committees overloading them with cruft and redundant features, and at the end of their healthspans, they become painful for all involved. In your list, this includes both PHP and ECMAScript; Perl 5 avoided this fate, but Raku certainly suffers from it.

[-] sxan@midwest.social 9 points 7 months ago

Tell me you drank the Rust Kool-Aid, without telling me you drank it.

load more comments (1 replies)
[-] Cirk2@programming.dev 5 points 7 months ago* (last edited 7 months ago)

Bringing more modern tools and features to existing large code bases is "destroying his reputation"? Bjarne and the committee is constantly extending and modernizing a language with code bases older than me. Yes that means the old stuff has to be kept around but that is the price of allowing existing code to migrate gracefully instead of just throwing it out of the window. There is a problem with some missing rails to enforce current and saver techniques but Bjarne is not denying that.

load more comments (1 replies)
load more comments
view more: next ›
this post was submitted on 19 Mar 2024
145 points (92.9% liked)

Programming

17314 readers
313 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