Tim Connors wrote:
[1] It's like back in uni when we were tasked with writing a BIGNUM handler in assembler. The memory allocator was brk(). I tried forever to write an allocator thinking that I could somehow reclaim memory once I finished with it. I was even going to do double indirection. But I failed, and decided just to do a half arsed job and get the rest of the project working. Then I found out that the pros only ever grow memory and never shrink it again, because when combined with fragmentation, you never have space at the end to be able to shrink. That's why you end up with bloated pigs like mozilla always ever expanding and never shrinking when you close a bunch of tabs. You can't shrink unless brk() takes a negative number and all your allocations were at the start of your heap. I wouldn't have invented *THAT* API!
*blink* - are you saying that bloatware (moco and friends) don't use malloc and free? WTF?! You'd think they can't read a manpage: $ man brk | grep malloc Avoid using brk() and sbrk(): the malloc(3) memory allocation package is the portable and comfortable way of allocating memory.