3 ms·
Leaking memory is not a "solution". Ever. Maybe for a commercial problem. But not for one in systems API design. If you copy, provide a new interface. It's tim
by fch42 3y ago
Leaking memory is not a "solution". Ever. Maybe for a commercial problem. But not for one in systems API design.
If you copy, provide a new interface. It's time-honoured and proven in Unix to give *_r() ones in such a case.
- jeroenhd 3y agoIt solves hard crashes during DNS lookups by wasting a few kilobytes of RAM. Seems like a fine solution to me. The memory leak only occurs in circumstances where the program would've crashed or started messing with random memory anyway. A proper solution would be to either nuke put/setenv() in the C standard library or redesign the *env() calls entirely, but that would break existing programs.
- JohnFen 3y agoA proper solution would be to implement your own put/setenv in the program that needs special behavior. That solves everything and does not affect any other programs.
- slaymaker1907 3y agoThere are circumstances where it's a perfectly valid solution. For example, suppose you're trying to acquire the lock on something to destroy it. It can be the lesser of two evils just to leak that memory instead of just waiting forever/a very long time to acquire that lock. You just need to ensure that you aren't leaking memory too quickly for whatever your constraints are. For example, most programs wouldn't care about a 1kb/day leak of memory because that would take a very long time to actually become noticeable. Furthermore, there's pretty much always some degree of memory growth just due to heap fragmentation (at least if you're using a language like C which can't do memory compaction via GC).