←back to thread

271 points mithcs | 3 comments | | HN request time: 0s | source
Show context
kerkeslager ◴[] No.45954593[source]
I feel like there might be some value in this header file for some projects, but this is exactly the wrong use case.

> In cgrep, parsing command-line options the old way is a breeding ground for CVEs and its bestiary. You have to remember to free the memory on every single exit path, difficult for the undisciplined.

No, no, no. Command line options that will exist the entire lifetime of the program are the quintessential case for not ever calling free() on them because it's a waste of time. There is absolutely no reason to spend processor cycles to carefully call free() on a bunch of individual resources when the program is about to exit and the OS will reclaim the entire process memory in one go much faster than your program can. You're creating complexity and making your program slower and there is literally no upside: this isn't a tradeoff, it's a bad practice.

replies(3): >>45954628 #>>45955473 #>>45957515 #
binaryturtle ◴[] No.45957515[source]
There are (older) OSes where this is NOT the case. Leaving things un-freed would leak memory after the application has terminated.
replies(2): >>45959168 #>>46007850 #
1. kerkeslager ◴[] No.46007850[source]
Sure. And the rare programmer reading this who is still using that OS knows they're the exception to the rule. To everyone else that fact is irrelevant.
replies(1): >>46014045 #
2. binaryturtle ◴[] No.46014045[source]
It still matters when you try to keep your components truly portable (aka you're not just targeting the big 3).
replies(1): >>46040931 #
3. kerkeslager ◴[] No.46040931[source]
Did you read the post you're responding to?