Hi everyone, thanks for all the comments. I want to clarify something important: This video shows how thinking in grouped lifetimes can help prevent common memory issues - it's a mental model, not a silver bullet. When you know your limits and group data by lifetime, a lot of memory issues become much easier to prevent, identify and fix. Arenas and pools are tools that support this way of programming, that's all. As for security, I'm sure there are more steps required. I'm not qualified to provide a comprehensive solution on that front and never claimed to do so. Memory safety is a huge topic and this is just one part. It's a first step to make the rest simpler. Start by thinking about your data lifetimes. Know your limits. Group things that live and die together. Build from there. Cheers, Dylan
YT autotranslate that does not recognize people speaking more than one language: "Die Situation der manuellen Speicherverwaltung ist verrückt" It is correctly translated but looks a bit weird.
What you are describing is an arena allocator. It's a commonly-used method that can make programs faster and memory management easier. But that's it. Easier. Use after free (UAF) and buffer overruns are still trivial to do accidentally. And that's the problem. We don't just care about UAF and co just because they are bugs, but because they are also very likely security vulnerabilities. In particular, UAF can typically lead to arbitrary code execution. For games, this is a HUGE issues when multiplayer comes into play. Imagine another player joins your session and now that player has full control over your computer. Fun. So if somebody says "C is dangerous," believe them. If you still write games in C, then I can only hope that you are never writing anything that connects to the internet or parses untrusted data.
@@rundevelopment It doesn't even solve memory leak, it just that instead of leaving dangling pointers, the array will fill up, which is exactly as bad.
Manual memory management (with batched lifetime allocators) is also substantially easier to do when you run on hardware that has virtually abundant memory - which applies to most programs. If your program only really requires
This isn't to say that languages that have built in garbage collectors aren't useful or practical, yet I personally prefer languages that do not have them or at least do not strictly have them on by default and force you into having to deal with them. To many work arounds for my liking. When I'm designing my program or application from the ground up, I prefer to have control over the object's lifetimes. Having that as a responsibility does tend to create more work on my end, yet it allows for me to layout, arrange, and design the interfaces and frameworks of my application. Even if I'm writing in C or C++ there are 3 to 4 levels or lawyers to work with. The most common three are the back end, the middle, and the user front end. The one layer that is often overlooked is even lower than the backend and this is the actual hardware - software interface itself. In some scenarios, I'll even have inline ASM code right in the middle of a C or C++ code block or visible scope. Why? Maybe I want to override what the compiler is doing because I want to maximize the hardware usage to have better cache coherency, or I want to make sure that the branch predictor is being invoked less frequently and when it does have to be used, it has a 90% accuracy of having a success rate of taking the correct branch the first time. Maybe I want to use vector intrinsics to unravel loops, to utilize the vector registers such as with SIMD instructions. I've been working with and around computers since before Intel's Pentium era going back to the end of the 8-bit and transition into the 16-bit era. I have plenty of experience. If you do not know how the memory works in your system, if you do not know how the ALU works in your system, if you do not understand what interrupts are and how they work. How registers are handled, etc. How do you think you are going to write a reliable and performant program for that system? This doesn't pertain to those who are just users of a given system, this pertains to those who are programming it, instructing it. Now going back to the idea of garbage collectors, as I have said, they do have their use cases, but they are not a one answer or solution that fits all and many times or more often than not, they tend to get in the way of what one is trying to do.
Along with grouping allocations, you should use handles instead of raw pointers. Using generations can ensure that the object it references still exists. The allocation can move and the handle can still work just fine.
Idk, it just kinda sounds like you abstract the malloc and free into a custom solution that has all the same issues. Use after free -> The pointer just got replaced by an ID, and the "pages" are managed by you, not the OS. Memory leaks -> You need to manually delete objects from the array, if you don't, eventually it's just full. Buffer overrun -> Even C++ relies on manual checking, but it's conveniently hidden in the class methods. So yea, I don't think you solved anything, just made it really rigid and hard to modify later on.
Use after free -> He literally said to use an arena allocator, which means that the pointers are available as long as they are accessible and cleared when leaving the scope, there is only ONE free. Memory leaks -> read above, there is only one FREE, so even if it happens, it's very easy to debug. Buffer overrun -> with constant array sizes the programmer should be able to not get here, otherwise is just a skill issue. Absolutely no programming language can know at compile time if you variable is in bounds or not while it is not const. So yeah, runtime code is needed, but something better then runtime code is having the array already allocated and knowing it's max size, which he stated you should.
@eptic-c You entirely missed my point, which is that while he technically doesn't leak memory in the traditional sense, he basically proposes a worse version of the same system, where the pointers got replaced by array indices. And saying "skill issue" after that is just peak comedy.
What a nice approach. One should be taught at the very beginning how to create trees as several big contiguous chunks of ram instead of new/delete each entry one by one.
The reason people are so hyped about the one specific so-called "memory-safe" language is because most of those people are web developers who never wrote C/C++ applications. Which is obvious because their memory management strategy is the same one you learn at your first DSA class in college.
It's a skill issue because they do not know or understand the hardware and what it can or cannot do and how your high-level code is compiled or translated into lower-level code such as ASM and how the assembler translates that into binary, machine op codes. I'm 100% self-taught with 0 formal education in computer science, or related fields and I've been working on very hard and complex C/C++ applications over the past 20 years. I do not do this for a living, more of a pique interest and hobbyist. Throughout the years going as far back as around 03-04 is when I started to dive into this. I graduated high school in 99 and I wasn't a stranger to computers. Our first home pc was in 92 with DOS 6.0 - Win 3.11 and even before that I had some or limited experience with computers through out elementary and middle school. I still remember learning how to write small programs back in 2nd and 3rd grade in Basic where that computer didn't even have an internal hard drive. It took cartridges on the side of the keyboard. The thing that I've seen happen over the past 30 years is we went from instructing the hardware bit by bit every cycle to a massive world wild army of script kiddies. Some of the projects that I have built and was successfully able to run with minimal to no errors after hours upon hours of debugging and unit testing were full-scale 3D Graphics Rendering / Game Engine from scratch with a robust Physics, Animation and Sound Engines, it did not include every single feature that you would find in preexisting engines such as Unreal or Unity at the time. I had worked on this in my spare time from about 05 - 17, but it wasn't just one project, I had done about 3 or 4 of these. One used DirectX 10, another DX 11, my very first was DX 9c. I've also done one in Legacy OpenGL, more modern OpenGL using GLSL which was fairly easy to pick up since I had some experience with DX's HLSL and then finally Vulkan. Other projects I had worked on was a Hardware Emulator specifically the 6502 for the NES. I even started to get into and research Compiler Design, Language Theory, and OS Design. It's been a long journey and even to this day over 20-30 years later I'm still always learning something new. Languages such as C/C++ are not going to hold your hand and do your job for you. They are a tool and it's all in how well you know your tool and how you decide to use it. With that, it's called handling it with care which comes back full circle to being a skill issue. It truly baffles me. I'm not saying that every 4-year school does this, but it appears that there are many 4-year college grads with a background in computer science or some other related field and they've been taught to fear and avoid pointers. So many of them aren't even sure how to do pointer arithmetic, bit twiddling, etc. It's not that hard, it's only Logic!
Or, in the case of some of us, we see the whole task of dealing with memory safety as unnecessary if the compile-time checks handle it all for us. Don't lump people together when you don't have a clue what they've actually done. I was a C developer in the 80s, a C++ developer in the 90s, and am a Swift + Kotlin developer now. Oh and right, I did some web development that I hated in the early 2000s because I needed the extra money. I choose Rust for my personal projects (lately) because I don't need to worry about shitty garbage collection and I don't have to write any memory allocation code myself. Not everyone is as you see it, and it makes you the a-hole when you generalize like that. Let's try your argument the other way around: "The reason people are so against the one specific so-called "memory-safe" language is because most of those people lack the skill to actually understand the complicated realities of systems programming, and just rely on old tutorials or aging knowledge from the 70s." Just as untrue as your statement.
Rust definitely gives me some peace of mind once threads and async get involved, but that's a pain in the ass even in Rust if you strive to do it efficiently
Nice video. The kinds of people that advocate for memory safety as a language feature are also the kinds of people that want to magically abstract away the idea of memory. Their programs run on abstract hardware, and as such they must be able to use memory as if it was a magic resource. Those kinds of people always run into memory problems because they never consider the machine as a physical entity. It is only natural that they hate C. C doesn't allow you to assume that memory is a free magical thing you can just get and discard. More and more compiler tools and complex language design just to constrain the programmer into a tiny box of possibilities. When the actual on hardware code could be much more simple if they just stopped and considered what the f*** they are doing and why. But they never will. Whatever. Skill issues.
Rust is for finding a way to deal with the monstrosity that is a modern web browser codebase and still somehow shipping updates in a timely manner. It’s not FOR you or us, but it’s funny bc programmers cargo-cult (groan) on it as if its approach is relevant to them. You’re correct but not because everyone else is just a pleb react dev that didn’t watch handmade hero. Programmers love a concept cult (see: the functional programming craze) and bandwagon it, like clockwork
@@999a0sFunny thing is Firefox doesn't even have a rust based web engine despite Mozilla making Servo as a Rust web engine. At some point, it stops being about the tech and more so legacy on top of rapidly changing web landscape, which is why Firefox can't be on Servo the way things are now with the company.
I've said this in many places but here we go again: Most of the problems with C are a direct result of its atrocious pointer syntax. You'll have a better understanding of pointers if you learn any assembly language first
Hi everyone, thanks for all the comments. I want to clarify something important:
This video shows how thinking in grouped lifetimes can help prevent common memory issues - it's a mental model, not a silver bullet.
When you know your limits and group data by lifetime, a lot of memory issues become much easier to prevent, identify and fix.
Arenas and pools are tools that support this way of programming, that's all.
As for security, I'm sure there are more steps required. I'm not qualified to provide a comprehensive solution on that front and never claimed to do so.
Memory safety is a huge topic and this is just one part. It's a first step to make the rest simpler.
Start by thinking about your data lifetimes. Know your limits. Group things that live and die together. Build from there.
Cheers,
Dylan
nice "this situation is crazy" title
the situation is crazy situation is crazy
YT autotranslate that does not recognize people speaking more than one language: "Die Situation der manuellen Speicherverwaltung ist verrückt"
It is correctly translated but looks a bit weird.
atleast the title didnt contain "question"
@@RenderingUser I propose: "the memory management question." Now ban me from C++.
I did not expect a poe 2 reference here; it is like two separate parts of my youtube feed decided to merge...
same 😂😂😂
What you are describing is an arena allocator. It's a commonly-used method that can make programs faster and memory management easier. But that's it. Easier. Use after free (UAF) and buffer overruns are still trivial to do accidentally.
And that's the problem. We don't just care about UAF and co just because they are bugs, but because they are also very likely security vulnerabilities. In particular, UAF can typically lead to arbitrary code execution. For games, this is a HUGE issues when multiplayer comes into play. Imagine another player joins your session and now that player has full control over your computer. Fun.
So if somebody says "C is dangerous," believe them. If you still write games in C, then I can only hope that you are never writing anything that connects to the internet or parses untrusted data.
@@rundevelopment It doesn't even solve memory leak, it just that instead of leaving dangling pointers, the array will fill up, which is exactly as bad.
Manual memory management (with batched lifetime allocators) is also substantially easier to do when you run on hardware that has virtually abundant memory - which applies to most programs. If your program only really requires
This isn't to say that languages that have built in garbage collectors aren't useful or practical, yet I personally prefer languages that do not have them or at least do not strictly have them on by default and force you into having to deal with them. To many work arounds for my liking.
When I'm designing my program or application from the ground up, I prefer to have control over the object's lifetimes. Having that as a responsibility does tend to create more work on my end, yet it allows for me to layout, arrange, and design the interfaces and frameworks of my application.
Even if I'm writing in C or C++ there are 3 to 4 levels or lawyers to work with. The most common three are the back end, the middle, and the user front end. The one layer that is often overlooked is even lower than the backend and this is the actual hardware - software interface itself.
In some scenarios, I'll even have inline ASM code right in the middle of a C or C++ code block or visible scope. Why? Maybe I want to override what the compiler is doing because I want to maximize the hardware usage to have better cache coherency, or I want to make sure that the branch predictor is being invoked less frequently and when it does have to be used, it has a 90% accuracy of having a success rate of taking the correct branch the first time. Maybe I want to use vector intrinsics to unravel loops, to utilize the vector registers such as with SIMD instructions.
I've been working with and around computers since before Intel's Pentium era going back to the end of the 8-bit and transition into the 16-bit era. I have plenty of experience.
If you do not know how the memory works in your system, if you do not know how the ALU works in your system, if you do not understand what interrupts are and how they work. How registers are handled, etc. How do you think you are going to write a reliable and performant program for that system?
This doesn't pertain to those who are just users of a given system, this pertains to those who are programming it, instructing it.
Now going back to the idea of garbage collectors, as I have said, they do have their use cases, but they are not a one answer or solution that fits all and many times or more often than not, they tend to get in the way of what one is trying to do.
Along with grouping allocations, you should use handles instead of raw pointers. Using generations can ensure that the object it references still exists. The allocation can move and the handle can still work just fine.
Cleanup is often more than just deleting memory. That said, arena based allocation is useful for the right kinds of things.
Idk, it just kinda sounds like you abstract the malloc and free into a custom solution that has all the same issues.
Use after free -> The pointer just got replaced by an ID, and the "pages" are managed by you, not the OS.
Memory leaks -> You need to manually delete objects from the array, if you don't, eventually it's just full.
Buffer overrun -> Even C++ relies on manual checking, but it's conveniently hidden in the class methods.
So yea, I don't think you solved anything, just made it really rigid and hard to modify later on.
Use after free -> He literally said to use an arena allocator, which means that the pointers are available as long as they are accessible and cleared when leaving the scope, there is only ONE free.
Memory leaks -> read above, there is only one FREE, so even if it happens, it's very easy to debug.
Buffer overrun -> with constant array sizes the programmer should be able to not get here, otherwise is just a skill issue. Absolutely no programming language can know at compile time if you variable is in bounds or not while it is not const. So yeah, runtime code is needed, but something better then runtime code is having the array already allocated and knowing it's max size, which he stated you should.
@eptic-c You entirely missed my point, which is that while he technically doesn't leak memory in the traditional sense, he basically proposes a worse version of the same system, where the pointers got replaced by array indices.
And saying "skill issue" after that is just peak comedy.
The slop thins
The slop thickens
What a nice approach. One should be taught at the very beginning how to create trees as several big contiguous chunks of ram instead of new/delete each entry one by one.
this is pretty much how I intuitively set things up, other than the free slot list idea, nice one.
The reason people are so hyped about the one specific so-called "memory-safe" language is because most of those people are web developers who never wrote C/C++ applications. Which is obvious because their memory management strategy is the same one you learn at your first DSA class in college.
It's a skill issue because they do not know or understand the hardware and what it can or cannot do and how your high-level code is compiled or translated into lower-level code such as ASM and how the assembler translates that into binary, machine op codes. I'm 100% self-taught with 0 formal education in computer science, or related fields and I've been working on very hard and complex C/C++ applications over the past 20 years. I do not do this for a living, more of a pique interest and hobbyist. Throughout the years going as far back as around 03-04 is when I started to dive into this. I graduated high school in 99 and I wasn't a stranger to computers. Our first home pc was in 92 with DOS 6.0 - Win 3.11 and even before that I had some or limited experience with computers through out elementary and middle school. I still remember learning how to write small programs back in 2nd and 3rd grade in Basic where that computer didn't even have an internal hard drive. It took cartridges on the side of the keyboard. The thing that I've seen happen over the past 30 years is we went from instructing the hardware bit by bit every cycle to a massive world wild army of script kiddies. Some of the projects that I have built and was successfully able to run with minimal to no errors after hours upon hours of debugging and unit testing were full-scale 3D Graphics Rendering / Game Engine from scratch with a robust Physics, Animation and Sound Engines, it did not include every single feature that you would find in preexisting engines such as Unreal or Unity at the time. I had worked on this in my spare time from about 05 - 17, but it wasn't just one project, I had done about 3 or 4 of these. One used DirectX 10, another DX 11, my very first was DX 9c. I've also done one in Legacy OpenGL, more modern OpenGL using GLSL which was fairly easy to pick up since I had some experience with DX's HLSL and then finally Vulkan. Other projects I had worked on was a Hardware Emulator specifically the 6502 for the NES. I even started to get into and research Compiler Design, Language Theory, and OS Design. It's been a long journey and even to this day over 20-30 years later I'm still always learning something new. Languages such as C/C++ are not going to hold your hand and do your job for you. They are a tool and it's all in how well you know your tool and how you decide to use it. With that, it's called handling it with care which comes back full circle to being a skill issue.
It truly baffles me. I'm not saying that every 4-year school does this, but it appears that there are many 4-year college grads with a background in computer science or some other related field and they've been taught to fear and avoid pointers. So many of them aren't even sure how to do pointer arithmetic, bit twiddling, etc. It's not that hard, it's only Logic!
Or, in the case of some of us, we see the whole task of dealing with memory safety as unnecessary if the compile-time checks handle it all for us. Don't lump people together when you don't have a clue what they've actually done. I was a C developer in the 80s, a C++ developer in the 90s, and am a Swift + Kotlin developer now. Oh and right, I did some web development that I hated in the early 2000s because I needed the extra money. I choose Rust for my personal projects (lately) because I don't need to worry about shitty garbage collection and I don't have to write any memory allocation code myself. Not everyone is as you see it, and it makes you the a-hole when you generalize like that.
Let's try your argument the other way around: "The reason people are so against the one specific so-called "memory-safe" language is because most of those people lack the skill to actually understand the complicated realities of systems programming, and just rely on old tutorials or aging knowledge from the 70s."
Just as untrue as your statement.
Rust definitely gives me some peace of mind once threads and async get involved, but that's a pain in the ass even in Rust if you strive to do it efficiently
Except it's statically checked by the language...
And the ones who are "native" C programmers don't care because it's normal to have memory errors?
Nice video. The kinds of people that advocate for memory safety as a language feature are also the kinds of people that want to magically abstract away the idea of memory. Their programs run on abstract hardware, and as such they must be able to use memory as if it was a magic resource. Those kinds of people always run into memory problems because they never consider the machine as a physical entity. It is only natural that they hate C. C doesn't allow you to assume that memory is a free magical thing you can just get and discard. More and more compiler tools and complex language design just to constrain the programmer into a tiny box of possibilities. When the actual on hardware code could be much more simple if they just stopped and considered what the f*** they are doing and why. But they never will. Whatever. Skill issues.
Rust is for finding a way to deal with the monstrosity that is a modern web browser codebase and still somehow shipping updates in a timely manner. It’s not FOR you or us, but it’s funny bc programmers cargo-cult (groan) on it as if its approach is relevant to them. You’re correct but not because everyone else is just a pleb react dev that didn’t watch handmade hero. Programmers love a concept cult (see: the functional programming craze) and bandwagon it, like clockwork
@@999a0sFunny thing is Firefox doesn't even have a rust based web engine despite Mozilla making Servo as a Rust web engine.
At some point, it stops being about the tech and more so legacy on top of rapidly changing web landscape, which is why Firefox can't be on Servo the way things are now with the company.
I never saw programming from this point of view
Had same experience with lag and started doing everything global.
Global variables FTW, and keep everything in Main() 😎 you’re welcome Internet.
I've said this in many places but here we go again: Most of the problems with C are a direct result of its atrocious pointer syntax. You'll have a better understanding of pointers if you learn any assembly language first
Thank you for sharing
C can be dangerous sure, but just code well
Well he talks about temporal memory safety (e. g. use after free) but I would like better spatial memory safety (e.g. bounds checking)