Can you elaborate? I know that it might misbehave (i.e. report false positives), but I only encountered that with more complicated code that deals either with b

Can you elaborate? I know that it might misbehave (i.e. report false positives), but I only encountered that with more complicated code that deals either with big-fat third party libraries or heavily optimized code where the developer e.g. did not initialize specific variables on purpose. However if you deal with "student" problems I do not think this is the case. E.g. I taught a similar course to students and they appreciated that instead of $ gcc -Wall -std=c99 foo.c $ ./a.out Segmentation Fault they got something like $ gcc -Wall -std=c99 -g foo.c $ ./a.out ... ==22907== Command: ./a.out ==22907== ==22907== Use of uninitialised value of size 8 ==22907== at 0x4004F5: bar (foo.c:42) ==22907== ==22907== Invalid write of size 1 ==22907== at 0x4004F5: bar (foo.c:42) ==22907== Address 0x0 is not stack'd, malloc'd or (recently) free'd ... when e.g. writing to unallocated memory. I know for sure that there were often programs that were believed to be correct by students (and worse, often really worked, but not realiable), but had actually memory errors that were mostly reported by valgrind. I am not proposing to confront them with valgrind's details (I do not even know them), but explain that there is this tool that is a package in every popular Linux distro and ready to use to find these evil memory bugs (and they can be hard to hunt down if you are new to the language). In particular I am interested in a false positive reported by Valgrind for a student exercise.