How to stay SAFE with UNSAFE code | Unity Engine

[@BlackJar72]

I didn't know C# even had this -- though it doesn't sound that scary if you learned C++ before C#. Learning what assemblies are and how to make them might be the next step, since I'm still relatively new to C# and have seen the term thrown around without a real explanation, while C++ and Java lack them (at least in the versions I learned, I'm a bit behind the times with those languages now).

[@ncpurge789]

This video is so good. The explanations and editing are clear. You just got yourself a subscriber! I hope to see more videos like this and I can see this channel getting real big!

[@forrestgump8312]

Hi, I've been a teacher for 5+ years trying to make educational videos interesting for kids around this topic blabla... but THIS VIDEO... ... 30 seconds in... .. THIS FORMAT.. .. IT WORKS .. you found it sir, the perfect balance between too much and too little educational vs entertaining 50/50 enjoyable and instructable VERY good job whoever you are! PS. this is the first video I've seen from you hope the others arent shit :D

[@ozanyasindogan]

Great video! I wish someone explained me that way what a pointer is 30 years ago :)

[@codingpeanuts]

That's some nice editing! Keep up the good work!

[@shmunkyman33]

Thank you so much for these videos! It's really piqued my interest in this kind of programming in Unity, although it's still pretty tricky to full understand. I tried messing around with your audio generation code and after a long while I was able to successfully get it to output white noise, but that process made me realize there really doesn't seem to be a whole lot of documentation online for how to go about using unsafe code, and there's even less for using the Burst compiler outside of the context of the Job system. I was curious how you went about learning how to write unsafe code correctly in Unity, and if you have any resources you could possibly share? Either way, thanks for the videos and keep them coming!

[@rhedgeco]

Wow! Thank you so much for the kind words. I'm glad to have helped. That's so awesome you were able to use the code from my previous video! I agree there is not much documentation on unsafe code in unity. It doesn't seem like unity has cared to get around to it. To be honest, most of my understanding comes from working with pointers in other languages, and going through the C# docs separate from unity. It's definitely targeted at more advanced users, but man is it worth the investment! I remember finding a lot of helpful tips early on for unity specifically however on the blog at www.jacksondunstan.com/ Have fun!

[@shmunkyman33]

@@rhedgeco Thanks for the recommendation! I've been reading through some articles on that blog and they seem really comprehensive. If you don't mind, I had another question: is there a particular motivation or limitation which made you decide to use the Burst Compiler but not the Unity Jobs system? Would the Jobs system just not be useful in this context? Too slow? Or is there some technical limitation, like this problem not being parallelizable?

[@rhedgeco]

Yeah good question. I should have explained in the video itself why I can't use jobs. It's because scheduling jobs can only be done from the main unity thread. All audio processing is done on a separate audio thread, which prevents us from using jobs unfortunately

[@lemetamax]

I actually understand this video perfectly. Nicely done!

[@rhedgeco]

Thanks! I'm glad it was easily digestible!

[@pedroalonsoms]

this is such a masterpiece of a video, keep up the good job!

[@BitwiseMobile]

Unsafe is such a misnomer. There isn't anything inherently unsafe with unmanaged code if you know what you are doing. You can just as easily crash a C# program as you can a C/C++ program. If you don't believe me try this code: void foo(int bar) { foo(bar+1); } foo(0); , so just because something is garbage collected doesn't mean it's safe from stupid code. The difference is that it's easier to write dumb code in C/C++ if you don't know what you are doing. That doesn't make the code unsafe, it makes the unskilled, unknowledgeable programmer unsafe. That's the case with any language though. I've been using C# since it was in alpha - my company was a Microsoft subsidarary and we were alpha and beta testers for C#. We rewrote our entire ISAPI layer in C#. Previously it was C++ mixed with some XML. If you got email from Outlook or Lotus Domino delivered to your blackberry or WML/WAP device in the early 00s then it was going through my code :).

[@DreadKyller]

As someone who's been programming for 20 years and would consider themselves a pretty skilled programmer by this point, I have to disagree. While I understand to an extent where you're coming from, I feel your comparison is not very good. I agree that code outside of an unsafe block isn't inherently safe, that's not really the point. Many modern languages include a number of safety features that help to prevent some situations that can cause major issues, and unsafe is simply the keyword saying "Said safety measures are not necessarily applied in this context". Your provided example there will hang the program for a while until an overflow causes an error. While this is indeed problematic, it's consequences pale in comparison to what can happen with bad usage of pointers. Since data by default in C# is garbage collected, pointers aren't guaranteed to still point to data, reading data from a stale pointer may just give weird results, writing to it could corrupt the program depending on what's currently stored there. Pointer addresses are also numeric, and you can increment and decrement them, meaning you could access memory relative to the location of some other data, which could be almost anything within program memory, including the part of memory that stores the actual executable code. What happens when you try to write a long to a memory location of an int, well pointers don't necessarily ensure type safety, you can cast the pointer to a pointer of another type, or do it through assignment, or if it's stale pointer maybe it previously pointed to a long but now it's an int, or a float, or some other type less than 64 bit, meaning writing to this location now may modify not just one but two values in memory. And this gets worse when dealing with pointers to pointers, because if the data gets modified in that case, or becomes stale, that memory data could be anything, but is now being treated as a pointer which could point to an unknown location in memory. What happens when you possibly modify data used in the writing or deletion of files on the filesystem? You may corrupt files or other programs, what happens if you end up modifying the executable application code? You may end up changing the logic which could cause a crash depending on the data, or you may even provide an invalid CPU instruction which could crash not just the application but the OS, etc, depending on how and when this could even brick the system in particularly severe cases. Those types of potential issues are far, far worst than a recursive call stack like in your example. Obviously many of the examples I provides there would require some pretty extreme levels of negligence, but the point is they are possible. Many modern languages instead of removing the functionality, because pointers are extremely useful when used well, they put them behind a warning so that those who do not know what they are doing will be less likely to mess with it. Maybe unsafe isn't the best phrasing, maybe "lesssafe" or something, but it gets the point across, those who know what they're doing can feel free to deal with it, but if you don't know how to work with pointers it's often very "unsafe" to do so. Even today, software written by very experienced developers have been exploited by hackers, many popular pieces of software written by very experienced developers have fallen victim to people finding a way to abuse the software to perform what is effectively arbitrary code execution do to how the program dealt with pointers and finding ways to force the value of specific memory addresses. While such exploits could still be possible without unsafe code, more of them were do to people working directly with pointers and overestimating how well they were using them.

[@ryanlockhart5328]

You basically made a smart pointer.

[@rhedgeco]

Yep pretty much lol

[@AceBillions]

You are good at explaining.

[@rhedgeco]

Thank you! Try my best 😁

[@SteelyEyedH]

Is there any issue getting games through iOS/android App Store approval when using unsafe code?

[@rhedgeco]

When uploading to app stores, they do not look at your code. They only care if the app works as advertised. So any usage of unsafe code is fine, as long as it doesn't crash your program or make it behave in an unexpected way.

[@gustavosalmeron2013]

In the NativeBox class you created, instead of creating _data and a T Data reference, is it okay to just use T Data {get; private set; } or are there other implications to it?

[@rhedgeco]

The issue is that data should usually be allocated outside of the managed space so that it isn't moved around. And a side affect of having to manage memory yourself is that using it like a managed object can lead to undefined behavior. See the comment on the GetUnsafeRef method for more on that.

[@MegaSemi]

Subbed!

[@theman3282]

RIIA

[@voxelvoid]

So the channel is dead now?

[@rhedgeco]

Lol my apologies. I've been in school and have been working on some projects on the side i haven't been comfortable sharing yet. I'm just getting started with this video stuff so I'm not used to the video process yet 😅 and i should probably just be more confident in my work! Thanks for the comment!!

[@FriedMonkey362]

Thanks mr.🌿🍆

[@rhedgeco]

Lol this brings me back to my schoolyard days