It's always good when a website wants to be helpful about potential #C #programming security issues. However, when giving explanations and advice, you should be quite careful to get the facts right. Case example: totorialspoint on gets():"This example shows what happens when the input string exceeds the size of the buffer, causing a buffer overflow. Only the first few characters that fit into the buffer are stored"There are several problems here.This example does not accurately show what happens when the input string exceeds the size of the buffer. The extra bytes are not just truncated like this "Handling Buffer Overflow" example suggests.All the characters are stored in the buffer, overwriting whatever is past the stack buffer, including the stack frame (which includes the saved registers and function return address). This easily leads to exploitable stack buffer overflow that can be used to gain code execution (assuming at least you can also gain information about app base addresses, or have some ROP gadgets at predictable addresses - and on legacy systems without ASLR it's typically a direct code execution #vulnerability).$ perl -e 'print "A" x 19' | gdb -q -ex r -ex bt ./xReading symbols from ./x...Starting program: /home/user/xEnter a string: You entered: AAAAAAAAAAAAAAAAAAAProgram received signal SIGSEGV, Segmentation fault.0x0000414141414141 in ?? ()#0 0x0000414141414141 in ?? ()#1 0x00007fffffffddd0 in ?? ()#2 0x0000555555555149 in frame_dummy ()#3 0x0000000155554040 in ?? ()#4 0x00007fffffffdde8 in ?? ()#5 0x00007fffffffdde8 in ?? ()#6 0x37751d6974463871 in ?? ()#7 0x0000000000000000 in ?? ()The correct advice? There is no way to "handle" buffer overflow with gets(). You must never use gets().The bad explanation is at:tutorialspoint.com/c_standard_