Compiling and running bufdemo -------------------------------------------------- (I did this on jupyter.bennington ... YMMV on other systems.) First try, with the default gcc options. jim@jupyter:attacks$ make bufdemo cc bufdemo.c -o bufdemo jim@jupyter:attacks$ ./bufdemo Type a string: 12 12 jim@jupyter:attacks$ ./bufdemo Type a string: 1234 1234 jim@jupyter:attacks$ ./bufdemo Type a string: 12345678 12345678 *** stack smashing detected ***: terminated Aborted (core dumped) Second try, explicitly turning off the "stack canary" checks described in section 3.10 of our textbook. Also while we're at it, optimize for debugging so that it's easier to use gdb to look at what's going on. jim@jupyter:attacks$ gcc -Og -fno-stack-protector bufdemo.c -o bufdemo jim@jupyter:attacks$ ./bufdemo Type a string: 12 12 jim@jupyter:attacks$ ./bufdemo Type a string: 1234 1234 jim@jupyter:attacks$ ./bufdemo Type a string: 123456 123456 jim@jupyter:attacks$ ./bufdemo Type a string: 12345678 12345678 jim@jupyter:attacks$ ./bufdemo Type a string: 123456789012345678 123456789012345678 Segmentation fault (core dumped) Notice that even though the buffer only had room for 3 characters, we had to type a lot more to get things to crash. This kind of crash is usually called a "segfault" - see for example https://en.wikipedia.org/wiki/Segmentation_fault . You mission, should you decide to accept it: run this code with gdb and explain what goes wrong. In particular, watch what happens to the stack while the input string is read in, and draw some diagrams of the stack at the start and the end of my_gets , in its "healthy" and "corrupted" state. This is similar to Practice Problem 3.46 in the textbook.