Memory safety in C++, Zig, & Rust (part 1)
Vložit
- čas přidán 1. 07. 2024
- Part 2: • Reference Cycles in Ru...
Code: github.com/contextfreecode/sa...
0:00 Intro
0:27 == C++ (cpp) ==
1:30 Returning expired memory
3:09 Pointers and values
4:02 Analyzing memory errors
6:09 Secret frees
7:19 Out of bounds
8:31 Initializing values
8:50 == Zig ==
9:33 Initializing values
9:50 Out of bounds
10:13 Explicit destruction and memory leaks
11:26 == Rust ==
12:13 Trying to return locals
13:00 Trying to ignore secret frees
13:50 Trying to set parent pointers
15:27 Out of bounds
15:54 Outro - Věda a technologie
My man just trying to mess with rust and the compiler be like I'm 10 dimensions ahead of you
Yea this is the thing people complain about you can't really mess with Rust. I've reached a point of understanding what the compiler wants but if you don't then you will have a hard time trying to just throw things together.
@@dyslexicsteak897 I think what most people struggles with rust is that because the language is just different, it throws people off right away since they've gotten too used to the way that they normally program applications.
I've also used rust for a while and despite that it forces you to have a different mindset, which is what makes the learning curve of rust so steep, but then you just kinda know how to use it as time goes by, accepting None and Err variant to be exists along with the "happy path" that you trying to program
And another thing that I can feel about using rust is that when you get back to program in other languages, you felt something is missing, you just felt that this thing might be throwing an error at anytime but the compiler doesn't tell you, you just feel "unsafe" and "unsure" about what you're doing and what the compiler will do, because the language is designed to make you program the way you want, and not the way that the computer want, in which errors are everywhere
It's basically like switching from vscode to neovim sort of feeling, it felt hard at first, but as you get used to what the benefits of the alternative offers, it really does feel weird switching back
@@vintagewander yea trying to use anything else is difficult now
That's the best showcase of Rust safety compared to other languages I've seen so far.
It may be safe. But it is soooo annoying!
@@vladimirkraus1438 I had so many frustrations with bugs in C and C++ that seeing "Rust's way" is refreshing. So far I only fighted the compiler on little toy programs. I bet on larger projects it's way more annoying haha
@@vladimirkraus1438 To be fair, cyclical references is intrinsically one of the hardest things to do in Rust. I believe the std implementation of things like linked list actually use unsafe for this.
@@mrlordbrutish There are things like linked list that as far as i know can't be done in safe rust. But that is why unsafe exists, create support for the link list, place it behind a safe api, and the rest of the language can remain safe. safety by default.
@@vladimirkraus1438 just like seatbelts. so annoying , but I get to live
God damnit! You can't leave us dangling here.
nice
God damn, nice showcase, waiting for the part 2. Love your videos man, keep it up.
Damn, ending on a cliffhanger! And just when it was getting spicy (rusty). Looking forward to part 2!
Explainin Rust tree traversal spans multiple videos. Poetic
That is the true rust way
Not really, if you brainlessly tuck Arc::new(Mutex::new(sth)) everywhere and call it a day.
@@stevenhe3462 I think in this case a good old Rc could do the trick, since there's no thread stuff going on anywhere... uh, maybe a RefCell
Yeah, part 2 for Rust is Rc.
Other ways to go could be either unsafe or showing ways to avoid feeling a need for parent pointers. Or maybe other approaches I'm not thinking of.
Rust is the other extreme it seems. Zig looks promising as it follows the middle path.
in Rust, the standard library does have some ways to represent this data structure. You can make each node (std::rc::Rc), and then represent the parents as another Rc, causing a memory leak (because cyclic strong reference), or even better you can represent the parent ref as a std::rc::Weak, which won't cause a memory leak.
But this also has its downsides; since it's no longer possible to say that a single node owns another (Rc models shared ownership) you can't guarantee unique mutability; so you're just not allowed to mutate them ever, which is not that great, because this means that you can't set a node's prent after it is a child, or vice versa. But you could use RefMut to explicitly model "dynamically checked references", which does the job of the borrow checker but at runtime. so to truly model the same parent/child relationship you need "children: Vec, parent: std::rc::Weak".
The reason I'm careful to fully write out std::rc::Weak's name here is because std::rc as well as RefMut are not threadsafe; which is something to think about (though Rust also won't let you do horrible things here, because even in single-threaded scenarios the compiler statically ensures nothing would go wrong when multithreading), and the solution is simple, just change it to "children: Vec, parent: Vec", which is more idiomatic Rust because, well, it's threadsafe, which doesn't mean exactly the same thing as in other languages. personally i love that Rust does give you the option for these dynamic checks in a way that's structurally sound without any opportunity for memory unsafety bugs, without making that the default, it doesn't hide the complexity required to model a certain data structure, you have to explicitly opt in to the additional overhead so you can do additional things
It seems GhostCells can help here. Need to check it myself though.
please write a blog post, this is too much quality writing for a youtube comment. It is not allowed :-)
@@mypersonalstuff-cy7gi I've considered this, actually. A while back I got similar advice when posting to Twitter (and to anyone who wants to nitpick the name change, I've never used "X" in any meaningful capacity), and considered that it may be useful. Although I guess I could write a "proper" blog post on this topic, I feel that the comment in its current state feels low-effort for a blog post. Maybe I can start a blog with like, a subsection of "micro posts" that are basically just high-quality youtube comments, like this one, with less of an independent structure.
Really good video. I hope you keep uploading nice things! Subscribed
Awesome video and start to a new series. Looking forward to part 2 :)
Holy shit. I love how you manage to find every possible memory safety error that Rust makes, one un/commented line at a time.
I can't wait to see how this would look in ROC (one day 😅)! the ROC people also have a pretty interesting case study of using both Rust and Zig, actually because of relative memory safety and capability
What is ROC?
Very informative video. Thank you for this!
Integer index to vector. Works every time.
i like how concrete zig is
Even learning it just feels like it makes sense, even down to pointers which I always struggled to grasp with C++. Really cool language overall
The chad zig. I hate the way rust is passive aggressive with you, and cpp, well...
Aaah, the cliffhanger
If you want a sneak peek, I do have the code already linked in the description. But the video should be more fun than just looking at code, I imagine.
Hey, not quite related to this video but i was wondering if you will be covering the Roc programming language in any of your future videos. I'm sure you have already have seen it and it developed quite fast and good (in my opinion) this year. It's one of the more interesting languages in the upcoming years i think
I agree with your assessment of its importance, and I do hope to cover it in the next few months. I've toyed with it just a little myself so far. I'm always so behind on everything, sadly.
@@contextfree I'm looking forward to your video! I think it could be interresting to have Richard Feldmann, the designer of Roc, on the video as well. Take your time, the language is still very much unknown, i can wait another few months for a video on it, maybe even more interresting new features have been added by then.
Me: Meh, such a simple thing as a node tree... it's easy. I know very well what I am doing.
Rust: No, you don't, you stupid.
Well, I was purposely causing as much trouble as possible. But it's clear from security alerts that this happens easily in real (usually more complicated) code frequently enough as well.
exactly, you don't. having children/parent pointers intrinsically unsafe because stuff can be moved around and then those pointers would be invalid. rust prevents you from doing this thing in SAFE rust because safe rust GUARANTEES that everything you can do has to be safe. if you can PROVE that in your particular case those intrinsically unsafe operations are fine ("sound"), then you can implement it with unsafe rust the exact same way you would do in C/C++, nothing more nothing less. there isnt any pointer magic that you can do in C and cannot do in rust. the difference is that to do intrinsically unsafe stuff in rust you have to mark it with, well.., unsafe. period
Great video
You brought memories when I wanted to try this new cool rust thing everyone is talking about with some toy programs. This language is literally problem in itself sometimes haha. I don't how much time you need to spend to be fluent.
Depending on your background and effort invested, I'd say count on 3 to 9 months to become very fluent in Rust, if not "expert". That's assuming you're actively using it for real projects every week, maybe every day, not just dabbling. (Edit: oh, and it's well worth this investment!)
5:24 sanitizer options for compilers
Good video 👍
It has got to be Weak pointers to the parent. This tripped me up once for a weekend lol.
Got those coming in the next video, too!
This made me want to learn Rust even harder, very cool video
subscribed
more Zig!
this is a great showcase of how painful rust can be. yes, you can make it work, but you're going to burn more calories than you think doing it, and it may end up a rube goldberg device before you're finished.
would you be interested to look into nushell?
I do need to do that sometime, yes.
Being a Rust programmer, seeing all the blatantly unsafe and unchecked memory operations you can do in C++ is like a nightmare. And here I thought that C only needing one byte to introduce a CVE was bad enough.
Trash programmer detected, Rust training wheels deployed.
@Watcher *timeout: the monitored command dumped core*
it's worth noting that this is a manufactured example meant to showcase all of the unsafe stuff you can do.
Eh. That's why standard teachings include not to do most of the things he did. Object/variable life cycle and heap/stack are important concepts. In a couple of seconds of looking at the code I was immediately drawn to the fact he was returning a local. It wasn't even a thought. It's painfully obvious.
Additionally, there are many of uses of containers which avoid pretty much everything he highlights. This is why STL containers and smart pointers have become so popular. With little effort and a couple set of very basic rules, nothing in his example would have existed. His usage specifically illustrates issues from very poor coding practices is fair. I don't disagree toe shooting is easy. But the implication it's representative of the bulk of the real world usage or that it's difficult to avoid, is not.
For an example, he's using references where pointers or pointers to pointers make far more sense. Or, perhaps properly design it such that the owning container is passed in rather than created below the stack. As it seems pretty implicit per life cycle, the structure is to persist outside the call stack. Which immediately tells you to create it outside the call stack. So on and so. But again, highlights why even moderately skilled C++ coders don't fall into these traps. Because it's fundamentally how you don't do things.
Accordingly, it's fair to point out, he went out of his way to create these problems. That should tell you something.
@@justanothercomment416 This whole video was created to illustrate all of the common pitfalls there are in C++ and how Rust makes them impossible. That being said, there is some truth in saying "no good C++ developer would ever write code like this," but they often do. Look at openssl heartbeat and heartbleed exploits.
Now, one example isn't nearly enough to prove that C or C++ itself is unsafe. It really is OpenSSL's fault, in fact people look down upon it and think that everyone should switch to LibreSSL (also written in C) because of how often they have security blunders.
I do not think that coming up with specific examples of low level bugs causing exploits is a very good argument. Any good programmer would know that they have to be careful reading user provided data, even if they were not using C or C++. SQL is a good example of this, a high level language, yet one simple mistake can lead to leaked information for millions of users. Python has eval, JS has exec.
What is the ‘time’ thing you’re using? Is it a package?
It's usually available by default on linux. Just say time followed by any command.
Rc right? I'm also writing a terminal ui library in rust so ye 😁😁
That's the upcoming video, yep!
Referring to child nodes as kids is hilarious.
Rust is C++ with seatbelts and ABS
Rust is a car with airbags opening every now and then
wtf is that c++ syntax?
Will D be ignored forever now? :(
Well I'm not a big expert in C++, what does that arrow syntax in function declarations mean? What does it do and when was it added ?
That's trailing return type rather than before the function. You only rarely need it for some template situations, but odd folks like me prefer using it consistently. Looks like it was added in C++11.
@@contextfree aha, got it... Thanks for info :)
2:13 u forgot -Wextra
You are such a troublemaker!
I personally feel like memory safety is a bit over stated. Memory bugs are on the same tier as logic bugs to me. I personally prefer using C for a lot of my applications even if it's possible to create memory bugs just because I prefer the language.
Call me crazy, but I prefer the simplicity C provides. When I read and write code I do not need to think about the code itself, I just need to think about the steps necessary to get a task done. It's a little more inconvenient to have to think about memory, but it doesn't bother me all that much; worrying about memory is much easier than worrying about high level issues.
It's worth noting that the code I am usually writing is relatively close to the operating system and so it's a lot easier to think about a task in terms of low level steps. I actually do not program all that often, especially not high level tasks. When I do program I like to challenge myself to write it as close to the OS as possible. I write system utilities in C without libc and exclusively using system calls, as opposed to writing them in Rust. As a result, they end up being less than a kilobyte in size each.
For the record, not using libc would not make your binary any smaller if you're not statically linking (in fact, it will probably make it larger since you're rolling out your own solution instead of using the libc that's likely already in the computer anyway). If using libc is an option at all, I see no reason to avoid it. If you work with embedded devices and such, rust is also a great option there.
And regarding the simplicity of the language, I'd say that's less a feature of the language and more of a feature of how used to it you are. If anything you can say it is less verbose, so you spend less time actually typing it out, but in any serious project the time you spend actually programming is a minority, you spend the majority of the time reading, debugging, and thinking out what you should do. Absolutely valid to just like C more though, I still love myself some C
But I really really REALLY cannot say enough that memory safety is NOT overstated. Microsoft reported that 70% (70%!!) of all vulnerabilities they find and address on their products come from memory safety, each year, for the last 12 years! From simple buffer overflows, to use after free errors, to heap corruption, even a single bad memory access is enough to cause arbitrary code execution, even on modern software and OSes, with all the builtin safeties (NX, PIE, canaries, RelRO...)
And the worst of all is that memory errors often don't cause issues when they happen, but later, making them exceptionally hard to debug (for instance, if you cause a heap corruption, the program might not segfault or even show any abnormal behaviour until one to several allocations later)
Please, take your memory safety seriously guys
@@pedrogodinho4649 First of all, I appreciate the long and well thought out reply. The replies I was expecting to receive would've looked a lot ruder.
In regards to your first claim that using libc would produce a similarly small executable, that would seem logical, however I have never had any success getting a very small binary that is also dynamically linked. Also, it's more fun to write it yourself, so why not?
Second, I absolutely agree that memory issues can cause significant security issues, as well as other issues such as degraded performance. However, I think a lot of people are exaggerating slightly. Most memory bugs, while sometimes well hidden, do not have any impact on security. I think that overall, the people who claim "nobody should ever use a memory unsafe language ever again" are just taking an extremist approach to the issue. I absolutely do take memory safety seriously, but I can sleep soundly knowing that there might be a memory bug in my code hiding somewhere.
On the topic of that 70% issue, that figure has a few issues. For one, a lot of other factors could come into play. That figure is based on bugs discovered (obviously, they cannot count bugs they have yet to discover), so it could also be reasonable to come to the conclusion that they are easier to find than regular bugs, correct? Another issue with this figure is that it is assuming something about all code bases based on a very small sample size. Most people do not directly claim that they think that 70% of all C bugs are memory bugs, or that this figure applies to all code bases, but I believe that is sort of what they're subconsciously getting at.
So in other words, that figure alone does not actually mean much, and can be interpreted in multiple ways.
I think that the D programming language should have also been showcased. D has bound checking, guaranteed default initializations, protection against dangling pointers by lifetime analysis (DIP25 and DIP1000), a @safe mode (which roughly emulates the guarantees of non-unsafe C# code) and even a prototypal borrow checker (@live functions).
I knew of some of those things, but this is the best single list I've seen. Thanks!
Is the safe by default mode for compiling D?
@@contextfree Not now, but @safe by default is intended to be implemented in the future, according to Atila Neves own statements in "My Vision Of D's Future". Besides, D is still deprecating heaps of unsafe or unnecessary features, while paving the ground for implementing language constructs like native tuples and co-routines, plus features like the aforementioned @live functions have not yet been perfected enough for use in coding, so it's expected that there will be a delay.
To ensure the project as a whole uses @safe code, you could consider applying the @safe attribute to the main function.
Aaaaaand D
These millions lifetimes for a simple struct (and it still doesn't compile or somehow it does compile but I don't know why) are one of the reasons I gave up rust. Just moved to cpp without c pointers and data-oriented design for better memory safety.
zig is a good option once it becomes more stable.
0:32 don't people call them children, and not kids?
yez
I think you should've clarified that this example was designed to show all the memory safety problems that can happen in a real-world project and how the different languages tackle these problems. Because of course returning a reference to a local variable in C++ isn't the right thing to do. But that doesn't mean that the C++ example is not relevant, since you tried to do exactly the same thing in all languages to see how they tackle the issue.
Memory safety in C++ 😂
Rust is so damn cool
C++ : you are free to break the rules, but only if you know what you are doing!
Rust: this is my house my rules and nothing else!
Rust is actually the tiger mom of programming languages. Change my mind.
More like c++: rules, nay they are more like guidelines anyway.
Rust: you are free to break the rules, but only if you explicitly say you know what you are doing!
@@someonespotatohmm9513 yup, that's more accurate
Now, take my unsafe
Personally, I just add this comment at the end of the main function:
//Let the os free the memory for me
One thing to remember is that just like there is life before main there is life after it. That can be used against you if your not safe.
no one: ...
rusters:
"why when I wrote shit code, compiler did not fix it????"
It looks like the video for Rust programmers.
To be fair, the C++ code is the equivalent of that "Where does the circle go? In the square hole" meme.
You purposefully wrote all that C++ code wrong, and it's semantically similar to writing your Rust example only with unsafe blocks and then complaining that Rust sucks because "nobody is stopping you from wrapping the code in unsafe".
When people demands implicit bound-checking, it amazes me everytime these days because range-for exists for a decade.
People blame C lets users run with scissors. C++ evolves so rapidly that you need no scissors in your hands anymore. You just need to write modern codes.
I can reject such a PR that you made in my Rust Project without looking at it - i can't with C++
@@hagbardceline9866 the sight of an asterisk or "new" in C++ is already ground for a PR rejection, without looking at it.
Also, how do you know if unsafe was necessary in the context of the PR or not?
Not quite... The point isn't to show real code examples, but show situations in which memory errors can occur and how the compiler and tooling for the languages can help you find and fix them. Unsurprisingly, since rust was literally built on the grounds of straight up preventing these errors, rust's compiler errors you out before you can even run the program. As C++ was not designed with this objective, there are obviously situations in which you can slip in memory safety problems into your code. That's what the video wants to show I think
I build projects in C++ but later jumped to C# because I could develop faster. Compiles faster as your code becomes more and more complex and is more readable.
Recently I jumped to Rust. Was a big brain challenge without classes, had to rethink my way to develop.
Beginning this week I was surprised that I could develop equally as fast as C#.
Later this week I discovered that I can actually develop faster in Rust than I can in C#. I mean complex code.
C# is still a favorite language but Rust is clearly now my number 1.
Yeah, Zig was much better than Rust here. And damn, Rust is very unreadable. It manages to be as bad as reading code in C++.
I don't know much about C++, but I always read that modern C++ is safer.
So it's not true?
Safer than old C++, not as safe as some newer languages.
Zig and Rust don't need to be backwards compatible with unsafe code, so they were built from the ground up for better static checks.
Value-based C++ with RAII for resource-managing classes is the key. However, people wish to look smart online and produce dangerous C++.
I heard that full memory and type safety are somehow available in modern C++, but, apparently, they are somewhere deep and have to be set up, idk. Sounds like a complete mess comparing to the Rust way
@@pedromiguelareias iterator invalidation is still something very common even if you stick to value semantics
As long as you have some IQ, stick to certain rules, use smart pointers and don't use any obscure and unsafe C functions you won't create any memory bugs. Don't listen to any retards saying C++ is an unsafe language and that's is why no one should use it bla bla. C++ was not created for retarded people, only for those who know what they do.
This is not the best example for C++. Why would you not return the tree instead of returning a reference. In fact the compiler warned you not to return a reference. You did it anyways by jumping through hoops
Yeah, a move in either C++ or Rust would make the most sense if I want the tree. This is just toy code showing how things can go wrong. Presumably real-world code more often hits bad things from just being more complicated in the first place.
@@contextfree C++17 has guaranteed return value optimization. So in this case you don't have to use std::move to get the best performance. Just returning the tree is infact the fastest, the most obvious and safest way .
That's why I think this toy example is actually wrong when it comes to showing how things can go wrong. But your point is correct. Yes, returning a reference to a stack object in C++ is bad.
I would say in C++ two good rules of thumb for such kind of errors is to not optimize prematurely and to not try to outsmart the compiler.
@@contextfree It also depends on what kind of C++ you are writing. Using modern C++ and taking advantage of the compiler (and not ignoring/silencing errors) is going to give you safe and concise code.
Using C++98 era style and practices will lead you into a deathtrap.
@@ajinkyakamat7053 Guaranteed RVO is nice for sure. It's still effectively a kind of move but in nicer form. And I think RVO is effectively the same thing as a move in Rust, except Rust describes it more easily in more contexts (including as function arguments) because of the differences in language semantics. Maybe there are differences between RVO and Rust moves that I haven't thought through properly, though. And maybe I should study it better sometime and make a video just about this. Might also be some Nim to bring in.
You can additionally use at a bare minimum:
-Werror -Wall -Wextra -pedantic -pedantic-errors
-Wall is very unfortunately named and includes almost nothing compared to using all of these warnings. On top of that, the clang-tidy static analyzer should help find further relatively obvious memory unsafety issues, but yeah...it's no match for rustc
Edit: you probably will want to specify the language standard as well with -std=c++17 for example. Unfortunately GCC defaults to using loads of GNU extensions to the standard without -std
So what I'm hearing is... All languages suck, it's just a matter of how. :-)
Or all languages are awesome! Buy yeah, they have they're own tradeoffs.
Damn, Adding those boilerplate lifetime tags in Rust is ugly. It's developer ergonomics suck and you can't perform the job in the end. Don't like it at all.
Indeed, it's the part of Rust I'm still less comfortable with, but like all concepts you get used to it and you only have to use them in specific cases. The compiler is getting smarter at helping with the syntax too.
The lifetimes are for explicit checking and declaring memory management, the objective of Rust is not to hide the low-level magic from developer but to allow him to stay safer and know very well how the final code will run
I work with rust professionally and I rarely have to use them.
You rarely have to use them and it's for your own benefit, not really a boilerplate as you might think
maybe you are just not smart enough
It’s more a how dumb can you program until you create a potential issue. Security wise this is all a none issue as the program is simply not accessible.
So... what's the advantage of Rust or Zig with respect to C++ ? Who, in the current economy. is going to invest the many millions that were dropped on C++ libraries, tools, software, gui toolkits and books? Zig looks good, as does Go, but failure is not an option, specially in poor countries.
Well, the advantage is safety, but that it's just one factor. You can't just throw away C++, it's hard to hire in new technolgies
I can't speak for Zig that I don't know, but Rust has already quite a large library though not anywhere comparable in maturity or scope. At this stage, it's certainly a little more adventurous than a well-established language - we see the same about Kotlin vs Java, and there are still endless discussions on many features. But the safety advantages should incite *some* companies to adopt it to avoid spending too much time on fixing bugs after the software is deployed on the field. A recent example of such adoption is the Linux kernel. Even Google is starting to use Rust instead of their Go language.
Microsoft just shipped Rust code in Windows, and many other corporations started using it too. And if companies invested millions in C++ they can do so with new languages as well, I don't see the problem.
What's the advantage compared to C++? Less bugs, and bugs cost a lot of money.
@@SaHaRaSquad I don't have a strong opinion. In Microsoft websites, C++ is still the preferred technology, with WinUI3 being available with C# and non-managed C++. It's not clear that Rust, Zig or Go will succeed in displacing huge investments. Too many offerings competing for attention.
@@pedromiguelareias I wonder what Google's Carbon role will play in this situation.
Rust is so annoying to watch. I can make the same memory safe code in Nim without any of that hustle.
yeah sure, and maybe in bash too...
Sure, sure that's what most rust fans do. Learn a bit of it, then go around and be schmuck towards anyone disagreeing with you.
@@maxpayne5056 well I surely didn't learn just "a bit of it" LOL. maybe you did. and maybe you didn't even understand what it's all about. you can't even begin to compare nim to rust. i hope you at least see that, otherwise you have no business in programming
@@itellyouforfree7238 Save it for someone else, you immediately proved my point. If replying to comments is your job, then how much programming you have time to do?
@@maxpayne5056 how the heck did i prove your point by explicitly saying you're downright wrong?! are you on drugs? moreover it's fucking sunday! do you expect me to be working at 5PM on a fucking sunday?!
Rust made C++ obsolete.
Using “kids” as an alternative nomenclature for “children” in computer science is stupid. 👎
As a non-native speaker, can I ask why?
Oh, I think I know: kids mean human. But children can refer to non-human objects.
Children also usually means human. I prefer "kids" because (1) it's shorter and (2) it has a standard plural. Both things make the code clearer. The only obvious con to me is that it's less common in code.
You're just saying that because your last name is child 🤣
@@wrong1029 I'm so slow.
This is just wrong.
Zig and Rust have awful syntax and trying to solve problems on wrong way.
Zig looks worse than newest C++ standard.
Rust have wrong premise that borrowing would solve all problems.
Please stop with this. This is not programming, this is fighting against compiler.
???????????????????????