If I had discovered your channel during my graduation my programming skills would have been on completely different level . But thanks any way for creating such content .
You, sir, are a life saver! We have a project where we have to implement our own version of sscanf function and one of the edge cases we thought of was a silly programmer trying to stuff a random number into the arguments of our function. We have been scratching our heads for two days now trying to avoid seg faults in such a case and this video is just what the doctor ordered. Love the channel and the effort you put into these, keep up the great work!
I hardly ever get segfaults on strings and stuff - even when they're malloced, since their lifespan is usually short and handled within a function (e.g. composing a filename). However, file pointers and pointer to complex, long lived objects (like a malloced struct containing other malloced members) - these are quite vulnerable. My trick is very easy: if I free memory or close a file, I also set the pointer concerned EXPLICITLY to NULL. That makes checking it very easy later on. BTW, for complex object I usually a free_object() function that builds on this principle, so that makes freeing them quite bullet proof. Another tip: make a centralized error function. That makes cleaning up after yourself quite simple. BTW: IMHO you're one of the very best channels on this subject, since I'm still learning things here after 35 years of writing C!
Hi Jacob! Your channel is THE BEST C LANGUAGE CHANNEL on TH-cam. I love pointers and I love this channel too! Please don't stop with this good job🙏. (Sorry if I typed something wrong)
OMG DUDE!!!!! Do you have any idea what you did there????? You just saved us from hours of (UGLY) debugging! For someone who tries to write a low level library for my languge, this is a true live saver. Of course, you can have the function normally accessing the pointer on release mode and then, execute the checks on debug mode. So, ZERO performance impact! Bro, one again, you are the BEST programming channel on YT!
Holy shit man. I remember looking for this once online and not managing to find it on stack overflow. This is some top tier programming right here. You are a wizard man!
Hay Jacob I really love the way you make your videos. Concise, great presentation and fun to watch. I would really like to see a video explaining how to use state machines in embedded development. Another video I'd like to see is what to look out for when we have several threads, how the sleep timing and the memory is determined. I've seen a lot of code with service function in which a state machine is run.
It's better to write if (NULL == p) than your variant. I you make mistake and write "=" instead "==" you'll get compilation error. In your case you will have only warning and "good" source for possible bug
@@SimGunther But this is just one blog that says rust and it's security is not better than c/c++, Others say rust is better than c/c++, Even Microsoft too
Very cool. Out of the two users you describe, I'm the later, writing libraries that mostly I will use. This is a great debug tool that I could see using in conjunction with the debugger, thanks.
I totally agree with you man. Just write clean code. Check your return values and always write cleanup procedures on failure..... However if we were really serious about this I would I would abstract malloc away and build some sort of ref counter and auto cleanup when the refs hit zero. However, you may agree that's a lot of work for something that's already implemented in other languages.
Abstracting malloc is definitely an option that I've used before, but it catches a different set of errors. It wouldn't, for example, help you predict whether or not a pointer is going to segfault. Also, the lack of type safety in C means that any data in memory can be a pointer, which makes C-based garbage collectors a little problematic. You can do it, but you need some constraints or assumptions.
Just a comment: writing into a pipe can block until the other end is read. Up to 4K will be fine but I think by default on linux the pipe buffer is 64K (that's customizable by the superuser). So it depends how many bytes we want to check. That said, pipe() may safely be used by writing a page size at one end, then reading a page size at the other end, one page at a time which makes it even slower for large numbers of bytes to check. Checking against "maps" in procfs will be ways faster, although more involved (parsing, maths)
This is something I've always wondered if it was possible to achieve in C. It might be really slow, but I think it could be handy to use this system while developing (and testing) your code, just to avoid random crashes that then you have to figure out without any clues. I think it can be useful.
This is pretty situational. In reality of you want to avoid this type of things you should use a debugger like GDB. So that you make sure step by step that you are not leaving bad pointers arround
Hi Jacob , Hope you doing great in this tough times around the world . I am also into system programming and I would like to request you for a thread debugging and synchronisation video if possible. Thank you for the content. Gratitude : India
I do have a few threads/synchronization videos, though they definitely don't cover everything. Check them out and let me know what you think I'm missing.
Is it recommended using this method to test how many bytes can be accessed with a given pointer? Say I'm writing a function taking void* only that can deal with various types of struct but in different sizes. Each struc has a special int tag to identify the exact type. The first step is to check if the given pointer is pointing to a large enough memory region before I can cast that pointer to certain struct and check the tag. If not, are there other ways to achieve that?
No, I would not recommend this for most code because it is very slow and does not give you more information than the segfault ("there was an error"). It would only be useful if you _absolutely must prevent the program from exiting_ (say because you are writing software for an airplane; and they probably use different techniques).
its probably still better to catch the fault and do error handling after the fact. The Reason is, that you dont want to slow down the 99.999% of users, that use your library correctly. Maybe there is already something like Structured Exceptions (__try) for windows and probably something else for unix. And if you are still writing in C maybe switch to C++ with only a bit of Seasoning.
The pipe() call and the two close() syscalls don't need to be done every time. We could keep "fd" static in the function (so that it's called on once) and rely on the kernel to automatically close the pipe ends for us upon program exit.
@@anon_y_mousse with "if" you could bout any argument. Jacob is not running on Windows and he never said it should, he also did not say it should run on VMS VAX or 8050 microcontroller. On Linux you can count on the kernel to tidy up after you. And for your info that's the same on Windows: files are closed automatically if you don't close them. Even MSDOS does that.
@@unperrier5998 No, MS-DOS does not clean things up for you, and it doesn't matter what system you're on, write clean code instead. There are too many sloppy programmers already, don't be one of them and don't encourage others to be one.
@@anon_y_mousse today you learned that msdos close files automatically: Int 21h, Function 4Ch: "This is the function call normally used to terminate your program. It returns control to the calling process (normally, but not necessarily, DOS). A return code can be passed to the calling process in the AL register. This return code can be tested with the DOS “IF ERRORLEVEL return code” command in a DOS batch file. All files opened by the current process will be automatically closed upon program termination. [...]" It's indeed a good practice to release resources. What part of the system does it is irrelevant. If you want belts and braces (meaning your program does it and the kernel does it again) then it's up to you.
@@unperrier5998 In other words, if you call a particular system function to exit your program it'll clean up at that point in time. If you don't call that function, it won't clean up. Do you not understand the difference? Calling that function is telling it to clean up, and it's not the only way to exit a program in DOS. There are more ways than one to allocate resources, and if you have a server that stays in memory after your program exits, then the memory that you tell it to allocate for you will NOT be cleaned up by the system. Again, write better code!
Ah, but what about the segmentation fault when the program was terminating? I looked at the code and there doesn't seem to be a reason for it. My guess is that the C library call has encapsulated the pipe routine's guts with a try catch block, and the segmentation fault is being captured and handled. I must admit, catching the exception would be my recommendation to solve this problem. Or, setting up a signal handler and catching the SIGSEGV, as you suggested.
You probably missed that he left in the invalid pointer from the original example, so it is that invalid pointer that is causing a seg fault, nothing to do with the pipe library.
When it encounters a 0 byte. When I wrote some functions for string operations I would often times set the last byte manually to 0. If you are using stringsin your own functions then this is arbitrary, you can make 10 be the terminating byte. However, keep in mind that printf, strcpy,, strlen, fputs etc. will all expect a 0 byre in the end of the string and your custom number will mean nothing to them.
What I was always taught was to make all pointers point to NULL unless I give them a defined address in my program. As a matter of fact, if we had what my teacher called a hanging pointer, we got a penalized. All pointers had to point to NULL or were given valid addresses in our programs. Basically they had to be heap allocation, pass by pointer, or used for data structures. Any and all declarations had to be initialized to NULL, and if we deleted/freed any memory that pointer had to be set back to NULL in the next statement.
It's solid advice, and as long as you don't forget to do one of those things, or mistype something you should be good. Basically, as long as you write bug-free code, you won't have bugs. 🤔
Can you make a video on the best cryptography C libraries and how to use it please ? Because picking C cryptography libraries libraries is quite confusing for someone switching from another programming language , especially because it's very important topic to keep sensitive data safe.
Are you needing help picking libraries or crypto algorithms? Typically, you figure out what sort of crypto algorithm you need (to provide the properties you want) and then try to find a library that provides that algorithm. But, yeah, we could do either in a future video.
Jacob Sorber I'm looking for a cryptography library which provides AES(rijndael) , SHA-256 and a secure random bits generation algorithm , So is there a library that provide those algorithms in c programming language? And thank you
@@leo69105 When it comes to computing students learning C I think it would help them figure out where the bug is much faster. It's not always gonna be as simple as "The invalid pointer came from this particular section of code". It might be the result of several branch decisions while the execution is several functions deep. What I'm saying is that such a setup might be a good set of training wheels while a student picks up on C. On the other hand, they could end up dependent on it instead of learning to use the debugger. :/ _Orrrrr you know, they could just learn Rust instead lol.( Just a joke. A good handle on C is very useful if you're a computing student)_
The only thing missing is an explanation that this check won't be able to tell you if the memory is read-only or writable. Although you could slow things down even worse by reading the data into a buffer and writing it back out, but then you get into concurrency issues.
I would think that a valid reason for wanting to test a pointer, would be to debug it, and figure out why it's bad based on its value, and how far off it is from its proper value
If anyone is considering doing this: don't. I cannot emphasize how bad this is, and not because it's slow as he mentions in the end of the video. I really thought he would redeem himself when he started talking about why you shouldn't do this, but I did a double take when he only mentioned performance concerns. The performance concerns are not even remotely the issue. Use after free is undefined. Undefined doesn't mean "if it doesn't crash, it's okay," it means it's undefined. It means as soon as you use after free the program is now in an undefined state and this _worse_ than crashing. Here's how this method will go very wrong: you malloc struct A and store a pointer PA to it, you free struct A, you allocate struct B of a different type and malloc reuses memory region of struct A, you check if the pointer PA is valid and since it's still in your address space then your function says it is, you write to struct A through pointer PA, struct B now contains garbage data. Or, a more common scenario: You allocate struct A and store the pointer PA, you free struct A, you check pointer PA and because the memory allocator hasn't yet returned that page to the OS this function will say it's valid, you write through pointer PA, that data is lost because no valid code will ever read it. Both of these are use after free scenarios that are very real that this function just doesn't detect. It cannot detect them. These are scenarios that you must assume will happen and when it does it will cause utterly baffling behavior that's almost impossible to reproduce. It will cause crashes that are difficult to diagnose. You will pore over every line of code that accesses struct B for hours and hours and you will never find where it is being corrupted. You will most likely not find the source of the bug unless you happen to catch it in a debugger. Doing this _will_ cause bugs that will lurk in your code and masks the one useful symptom of a use after free: segfaulting. You want your programs to segfault. The segfault lets you know something is wrong so you can fix the use after free.
Breathe. I completely agree with you, but I think you're also misunderstanding the point of the video. It is not prescriptive in any way. I just wanted to see if it was possible. So, I didn't provide a thorough description of the virtues of program crashes. Good idea for a future video, though. Thanks. I'll see if I can redeem myself. 😀
Hi jacob I see that you really like clang , is there a special reason you don't use gcc ? Just curious 😉 Btw your channel is a goldmine, I recommended it to all my friends who code in c/cpp , your videos are short and pinpoint accurate, thank you!
In most cases valgrind finds the lines of code that are responsible for the seg fault. I started using valgrind because I saw a video on this very channel about it. I swear my emotional reaction to seeing seg fault changed after just a few usages of Valgrind because I saw that in most cases it locates where the seg fault occured immediately and it tells you all the lines of code that are in the chain leading to the seg fault happening.
@@smrtfasizmu6161 Ya know, I have played around with valgrid a little bit in the past, but I always forget it exists when I actually need it. But yes, there's no doubt that it's incredibly useful for tracking down those kinds of errors.
I mean yes - but no. Dereferencing NULL is "just" undefined behaviour. it depends on the hardware, the OS and often even some configurations. NULL isn't even a specified address - it just most often is the same as the memory-address 0 and that can be a valid address.
If I had discovered your channel during my graduation my programming skills would have been on completely different level . But thanks any way for creating such content .
You, sir, are a life saver!
We have a project where we have to implement our own version of sscanf function and one of the edge cases we thought of was a silly programmer trying to stuff a random number into the arguments of our function. We have been scratching our heads for two days now trying to avoid seg faults in such a case and this video is just what the doctor ordered. Love the channel and the effort you put into these, keep up the great work!
I hardly ever get segfaults on strings and stuff - even when they're malloced, since their lifespan is usually short and handled within a function (e.g. composing a filename). However, file pointers and pointer to complex, long lived objects (like a malloced struct containing other malloced members) - these are quite vulnerable.
My trick is very easy: if I free memory or close a file, I also set the pointer concerned EXPLICITLY to NULL. That makes checking it very easy later on. BTW, for complex object I usually a free_object() function that builds on this principle, so that makes freeing them quite bullet proof. Another tip: make a centralized error function. That makes cleaning up after yourself quite simple.
BTW: IMHO you're one of the very best channels on this subject, since I'm still learning things here after 35 years of writing C!
Hi Jacob!
Your channel is THE BEST C LANGUAGE CHANNEL on TH-cam. I love pointers and I love this channel too!
Please don't stop with this good job🙏.
(Sorry if I typed something wrong)
Just wanted to show my appreciation for Jacobs Content
Thanks. I'm glad you're enjoying it.
OMG DUDE!!!!! Do you have any idea what you did there????? You just saved us from hours of (UGLY) debugging! For someone who tries to write a low level library for my languge, this is a true live saver.
Of course, you can have the function normally accessing the pointer on release mode and then, execute the checks on debug mode. So, ZERO performance impact! Bro, one again, you are the BEST programming channel on YT!
Holy shit man. I remember looking for this once online and not managing to find it on stack overflow. This is some top tier programming right here. You are a wizard man!
Write clean code, otherwise learn GDB 😁😁. Thanks for this one, more power 👏👏👏
You're welcome, as always, Artemio. Thanks for being here.
Even better; Both :P
Hay Jacob I really love the way you make your videos. Concise, great presentation and fun to watch. I would really like to see a video explaining how to use state machines in embedded development. Another video I'd like to see is what to look out for when we have several threads, how the sleep timing and the memory is determined. I've seen a lot of code with service function in which a state machine is run.
Thanks, Mino. I'll add it to the list and see what I can do.
@@JacobSorber Subscribed!
"Mom can we get Rust"
"We have memory safety at home"
Memory safety at home: if p == NULL return 0
It's better to write if (NULL == p) than your variant. I you make mistake and write "=" instead "==" you'll get compilation error. In your case you will have only warning and "good" source for possible bug
Still waiting till Jacob tries Rust
I know. I'll get there eventually. 🙂
@@JacobSorber Evidence is to the contrary, but I'd love to see some Rust safety features in C++ in the future ;)
www.viva64.com/en/b/0733/
@@SimGunther But this is just one blog that says rust and it's security is not better than c/c++, Others say rust is better than c/c++, Even Microsoft too
"You don't like good, clean, correct code" 😂
Very cool. Out of the two users you describe, I'm the later, writing libraries that mostly I will use. This is a great debug tool that I could see using in conjunction with the debugger, thanks.
I totally agree with you man. Just write clean code. Check your return values and always write cleanup procedures on failure..... However if we were really serious about this I would I would abstract malloc away and build some sort of ref counter and auto cleanup when the refs hit zero. However, you may agree that's a lot of work for something that's already implemented in other languages.
Abstracting malloc is definitely an option that I've used before, but it catches a different set of errors. It wouldn't, for example, help you predict whether or not a pointer is going to segfault. Also, the lack of type safety in C means that any data in memory can be a pointer, which makes C-based garbage collectors a little problematic. You can do it, but you need some constraints or assumptions.
Just a comment: writing into a pipe can block until the other end is read. Up to 4K will be fine but I think by default on linux the pipe buffer is 64K (that's customizable by the superuser). So it depends how many bytes we want to check.
That said, pipe() may safely be used by writing a page size at one end, then reading a page size at the other end, one page at a time which makes it even slower for large numbers of bytes to check.
Checking against "maps" in procfs will be ways faster, although more involved (parsing, maths)
"fix your code" - this is truly brilliant advice
3:30 My instinct: `size_t len` please 🤣🤣🤣
This is something I've always wondered if it was possible to achieve in C. It might be really slow, but I think it could be handy to use this system while developing (and testing) your code, just to avoid random crashes that then you have to figure out without any clues. I think it can be useful.
This is pretty situational. In reality of you want to avoid this type of things you should use a debugger like GDB. So that you make sure step by step that you are not leaving bad pointers arround
Interesting. Thank You.
Nice trick Jacob ! Thanks !
You're welcome.
Hi Jacob ,
Hope you doing great in this tough times around the world .
I am also into system programming and I would like to request you for a thread debugging and synchronisation video if possible.
Thank you for the content.
Gratitude :
India
I do have a few threads/synchronization videos, though they definitely don't cover everything. Check them out and let me know what you think I'm missing.
You are levelling up day by day.. At this rate, I guess you'll be on Netflix soon :D
Thanks. What do you think I should call my future Neflix show? I just want to be ready when they call. 😀
@@JacobSorber CodeBender :D
Is it recommended using this method to test how many bytes can be accessed with a given pointer? Say I'm writing a function taking void* only that can deal with various types of struct but in different sizes. Each struc has a special int tag to identify the exact type. The first step is to check if the given pointer is pointing to a large enough memory region before I can cast that pointer to certain struct and check the tag. If not, are there other ways to achieve that?
No, I would not recommend this for most code because it is very slow and does not give you more information than the segfault ("there was an error"). It would only be useful if you _absolutely must prevent the program from exiting_ (say because you are writing software for an airplane; and they probably use different techniques).
its probably still better to catch the fault and do error handling after the fact. The Reason is, that you dont want to slow down the 99.999% of users, that use your library correctly. Maybe there is already something like Structured Exceptions (__try) for windows and probably something else for unix. And if you are still writing in C maybe switch to C++ with only a bit of Seasoning.
Thanks Jacob.
You're welcome!
Hello sir. I am Himanshu Sharma from India. I love the way you come up with very good topics. I wonder if you can have some coding challenge series
Nice trick! But it will fail for larger blocks of memory because write will block. I do not know the size at which is will block.
Good point. Thanks. If you want to handle large blocks, we could take it in chunks.
@@JacobSorber yes - by reading the data back.
can you get the source code for the write function and see what it's calling to detect the segfault?
The pipe() call and the two close() syscalls don't need to be done every time.
We could keep "fd" static in the function (so that it's called on once) and rely on the kernel to automatically close the pipe ends for us upon program exit.
Don't rely on the system to close things for you, what if your code was running on a Windows system.
@@anon_y_mousse with "if" you could bout any argument.
Jacob is not running on Windows and he never said it should, he also did not say it should run on VMS VAX or 8050 microcontroller.
On Linux you can count on the kernel to tidy up after you. And for your info that's the same on Windows: files are closed automatically if you don't close them. Even MSDOS does that.
@@unperrier5998 No, MS-DOS does not clean things up for you, and it doesn't matter what system you're on, write clean code instead. There are too many sloppy programmers already, don't be one of them and don't encourage others to be one.
@@anon_y_mousse today you learned that msdos close files automatically:
Int 21h, Function 4Ch:
"This is the function call normally used to terminate your program. It returns control to the calling process (normally, but not necessarily, DOS).
A return code can be passed to the calling process in the AL register. This return code can be tested with the DOS “IF ERRORLEVEL return code” command in a DOS batch file.
All files opened by the current process will be automatically closed upon program termination. [...]"
It's indeed a good practice to release resources. What part of the system does it is irrelevant. If you want belts and braces (meaning your program does it and the kernel does it again) then it's up to you.
@@unperrier5998 In other words, if you call a particular system function to exit your program it'll clean up at that point in time. If you don't call that function, it won't clean up. Do you not understand the difference? Calling that function is telling it to clean up, and it's not the only way to exit a program in DOS. There are more ways than one to allocate resources, and if you have a server that stays in memory after your program exits, then the memory that you tell it to allocate for you will NOT be cleaned up by the system. Again, write better code!
i love the way u teach
Thanks.
interesting. i get that such a thing should never go into production code, but would it be reasonable to include such checks in a debug assertion?
Interesting idea. Is it portable tho? "Pipe" is POSIX.
Joke aside, I wondered about this before and enjoyed the video (and the deeper comments). Take that as one data point in favor of "more like this".
Thanks, Martin. Glad you enjoyed it.
We only just got notified of this upload
Ah, but what about the segmentation fault when the program was terminating? I looked at the code and there doesn't seem to be a reason for it. My guess is that the C library call has encapsulated the pipe routine's guts with a try catch block, and the segmentation fault is being captured and handled. I must admit, catching the exception would be my recommendation to solve this problem. Or, setting up a signal handler and catching the SIGSEGV, as you suggested.
You probably missed that he left in the invalid pointer from the original example, so it is that invalid pointer that is causing a seg fault, nothing to do with the pipe library.
when you use a char pointer as a string, how does the function that reads it know where the string ends?
In C a string terminates with a NIL character (ASCII code 0). So "Battle Master" is actually "Battle Master\0". The function stops at that.
When it encounters a 0 byte. When I wrote some functions for string operations I would often times set the last byte manually to 0. If you are using stringsin your own functions then this is arbitrary, you can make 10 be the terminating byte. However, keep in mind that printf, strcpy,, strlen, fputs etc. will all expect a 0 byre in the end of the string and your custom number will mean nothing to them.
That was neat! Thanks for posting!
You're welcome. Glad you enjoyed it.
I do embedded I never get seg faults
In embedded there are different types of exception, like "Hard Fault"
What I was always taught was to make all pointers point to NULL unless I give them a defined address in my program. As a matter of fact, if we had what my teacher called a hanging pointer, we got a penalized. All pointers had to point to NULL or were given valid addresses in our programs. Basically they had to be heap allocation, pass by pointer, or used for data structures. Any and all declarations had to be initialized to NULL, and if we deleted/freed any memory that pointer had to be set back to NULL in the next statement.
It's solid advice, and as long as you don't forget to do one of those things, or mistype something you should be good. Basically, as long as you write bug-free code, you won't have bugs. 🤔
I have made piece with pointers, I want to learn alot more about them
Can you make a video on the best cryptography C libraries and how to use it please ?
Because picking C cryptography libraries libraries is quite confusing for someone switching from another programming language , especially because it's very important topic to keep sensitive data safe.
Are you needing help picking libraries or crypto algorithms? Typically, you figure out what sort of crypto algorithm you need (to provide the properties you want) and then try to find a library that provides that algorithm. But, yeah, we could do either in a future video.
Jacob Sorber
I'm looking for a cryptography library which provides AES(rijndael) , SHA-256 and a secure random bits generation algorithm ,
So is there a library that provide those algorithms in c programming language?
And thank you
2:49 LOL
This would be pretty useful in the debugging process if it's behind a macro that can be preprocessed away by cpp when it comes to the final build.
Not really, because the cpu/os already detect these kinds of errors for you (issueing the segfault) and do so much quicker.
@@leo69105 When it comes to computing students learning C I think it would help them figure out where the bug is much faster. It's not always gonna be as simple as "The invalid pointer came from this particular section of code". It might be the result of several branch decisions while the execution is several functions deep. What I'm saying is that such a setup might be a good set of training wheels while a student picks up on C. On the other hand, they could end up dependent on it instead of learning to use the debugger. :/
_Orrrrr you know, they could just learn Rust instead lol.( Just a joke. A good handle on C is very useful if you're a computing student)_
The only thing missing is an explanation that this check won't be able to tell you if the memory is read-only or writable. Although you could slow things down even worse by reading the data into a buffer and writing it back out, but then you get into concurrency issues.
Can i become an embedded system engineer with a computer science degree?
I did.
with good ol' printf
"Just don't have bad pointers".
Me as a game programmer: wha?
I would think that a valid reason for wanting to test a pointer, would be to debug it, and figure out why it's bad based on its value, and how far off it is from its proper value
If anyone is considering doing this: don't. I cannot emphasize how bad this is, and not because it's slow as he mentions in the end of the video. I really thought he would redeem himself when he started talking about why you shouldn't do this, but I did a double take when he only mentioned performance concerns. The performance concerns are not even remotely the issue.
Use after free is undefined. Undefined doesn't mean "if it doesn't crash, it's okay," it means it's undefined. It means as soon as you use after free the program is now in an undefined state and this _worse_ than crashing. Here's how this method will go very wrong: you malloc struct A and store a pointer PA to it, you free struct A, you allocate struct B of a different type and malloc reuses memory region of struct A, you check if the pointer PA is valid and since it's still in your address space then your function says it is, you write to struct A through pointer PA, struct B now contains garbage data.
Or, a more common scenario: You allocate struct A and store the pointer PA, you free struct A, you check pointer PA and because the memory allocator hasn't yet returned that page to the OS this function will say it's valid, you write through pointer PA, that data is lost because no valid code will ever read it.
Both of these are use after free scenarios that are very real that this function just doesn't detect. It cannot detect them.
These are scenarios that you must assume will happen and when it does it will cause utterly baffling behavior that's almost impossible to reproduce. It will cause crashes that are difficult to diagnose. You will pore over every line of code that accesses struct B for hours and hours and you will never find where it is being corrupted. You will most likely not find the source of the bug unless you happen to catch it in a debugger. Doing this _will_ cause bugs that will lurk in your code and masks the one useful symptom of a use after free: segfaulting. You want your programs to segfault. The segfault lets you know something is wrong so you can fix the use after free.
Breathe. I completely agree with you, but I think you're also misunderstanding the point of the video. It is not prescriptive in any way. I just wanted to see if it was possible. So, I didn't provide a thorough description of the virtues of program crashes. Good idea for a future video, though. Thanks. I'll see if I can redeem myself. 😀
Hi jacob I see that you really like clang , is there a special reason you don't use gcc ? Just curious 😉
Btw your channel is a goldmine, I recommended it to all my friends who code in c/cpp , your videos are short and pinpoint accurate, thank you!
Segmentation fault (core dumped)
^^^ This appears in my nightmares
In most cases valgrind finds the lines of code that are responsible for the seg fault. I started using valgrind because I saw a video on this very channel about it. I swear my emotional reaction to seeing seg fault changed after just a few usages of Valgrind because I saw that in most cases it locates where the seg fault occured immediately and it tells you all the lines of code that are in the chain leading to the seg fault happening.
@@smrtfasizmu6161 Ya know, I have played around with valgrid a little bit in the past, but I always forget it exists when I actually need it. But yes, there's no doubt that it's incredibly useful for tracking down those kinds of errors.
True programers write programs which use 0 bits of memory and don't need pointers
How about kernel modules 💀
Even better, check pointers are properly used statically
I do bare-metal, so if I write to 0, I would probably just wipe out the reset vectors. No worries, just don't hit that reset button.
this get even frustrating when using some cross platform function loaders.
I mean yes - but no.
Dereferencing NULL is "just" undefined behaviour. it depends on the hardware, the OS and often even some configurations.
NULL isn't even a specified address - it just most often is the same as the memory-address 0 and that can be a valid address.
This is so interesting. It never occurred to me that I could use pipes for catching bad pointers.
I know. It's fun to think about how things can be repurposed.
low level scary ;-;
Waddya tryin' to do here? Make C safe?! Maybe next you could end all poverty and cure all diseases.
SafER? I guess maybe a little… sometimes…
Nope. That would be way too ambitious. Mostly just messing around.
,
Ha! First