From f5e9c84fdc8a65ec348397e2ddcf744b6d55b968 Mon Sep 17 00:00:00 2001 From: Jack Bond-Preston Date: Thu, 5 Jan 2023 19:55:43 +0000 Subject: [PATCH] update cheri article --- _posts/cheri/2022-11-19-cheri.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/cheri/2022-11-19-cheri.md b/_posts/cheri/2022-11-19-cheri.md index 110ed63..59c9be8 100644 --- a/_posts/cheri/2022-11-19-cheri.md +++ b/_posts/cheri/2022-11-19-cheri.md @@ -48,7 +48,7 @@ that's not supposed to happen! his name has spilled over into our `my_perfect_st `fgets()` fills up `user_name`, but it hasn't finished with the name yet! it doesn't care (or know) that `user_name` is full, it's just going to keep going until it finishes our user input, or reads 999 characters from standard input. thus it keeps mindlessly writing, overwriting the section memory we've used to store our precious perfect string (which happens to be immediately after `user_name`). -`fgets()` has a cousin, `gets(char *s)`, which is particularly poor with regards to memory safety, [and has largely been moved away from in modern C](https://linux.die.net/man/3/fgets): +***note:*** `fgets()` has a cousin, `gets(char *s)`, which is particularly poor with regards to memory safety (due to lack of `size` parameter), [and has largely been moved away from in modern C](https://linux.die.net/man/3/fgets): > LSB deprecates `gets()`. POSIX.1-2008 marks `gets()` obsolescent. ISO C11 removes the specification of `gets()` from the C language, and since version 2.16, glibc header files don't expose the function declaration if the `_ISOC11_SOURCE` feature test macro is defined. let's take a look at the stack in GDB to see how this happens: