2 ms·
It’s definitely inelegant. But I wouldn’t say it’s entirely without merit. If you’re writing a very simple “sed” like utility then you could probably get away
by hnlmorg 3y ago
It’s definitely inelegant. But I wouldn’t say it’s entirely without merit.
If you’re writing a very simple “sed” like utility then you could probably get away without freeing.
That all said, the kind of problems were freeing becomes complicated is generally the kind of software that is more complex than your typical “sed” command. So the advise of not freeing doesn’t really address the domain where freeing is a risk.
- codetrotter 3y agoKind of sucks for the first person that tries to process a really big file with it. Programmer never free’d, and only ran it on files that were like some hundred megabytes big. Some poor schmuck tries to process a 15 GB file on his 8 GB RAM machine, and after running for hours it crashes because of the lack of free :(
- hnlmorg 3y agoThat’s assuming each byte and/or line item is a new allocation rather than reusing already allocated memory for lines that have already been parsed. Plus not every utility needs to consider large file usage. Eg a date/time formatter. To be clear, I’m not advocating that people shouldn’t free. Just saying things aren’t always black and white. A great example of this is one of Americas missile guidance systems famously has a memory leak. But it runs out of memory after its maximum range anyway. So the memory leak doesn’t affect the performance of the missile in any scenario. Technology is often nuanced.