Some C/C++ developers use the convention of not bothering to free memory at the point where an application will immediately terminate, either by invoking exit(), or returning an integer value from the main() CLI entrypoint. This convention has the benefit of finishing the application a little more quickly, and also uses less code. Could leak checks provide an option to ignore this situation? Leaks are mainly a problem for long-running programs, especially loops, not where program termination is imminent.
This is, as you say quite normal, which is why memory that is still reachable at exit is not reported as a leak. Only memory that is no longer reachable is reported by default, which effectively does what you want I think. If you have explicitly asked for it then valgrind will report every block that is still allocated.
I'm not the best C/C++ programmer, but I am learning about manual memory management, and I have a small example app that I believe should not require manual free(). However, valgrind is reporting that hex_buf is lost unless I free() it, even though I immediately return from main() at this point. https://gist.github.com/mcandre/1ac317f0ee1381e8609561b2b246d6fa#file-fewer-c-L92 Am I doing this correctly? Should I perhaps use exit() instead of return to indicate this more clearly to valgrind?
That is lost yes because the only pointer to it is on the stack and once you exit that pointer is no longer in scope. You're right it's not strictly necessary to free that but it's a fairly unusual thing to see in real world programs because it can only really apply to things allocated by main or trivial children of main so in a program of any size that isn't things will normally work.