libpcap

> what if this code becomes a library and is integrated as part of a long-lived program Cue one of my favourite comments[1]: /* * We divy out chunks of memory rather than call malloc each time so * we don't have to worry about leaking memory. It's probably * not a big deal if all this memory was wasted but if this ever * goes into a library that would probably not be a good idea. * * XXX - this *is* in a library.... */ (Of course, this consideration should be appropriately downweighted by YAGNI, as threading memory management through prototype or internal utility code can by itself easily force it into very non-prototype territory wrt effort.) [1] https://github.com/the-tcpdump-group/libpcap/blob/2180b6e56a...

There are a couple of approaches that might legitimately be simpler than using a general-purpose allocator: in a single-pass batch process, just throw things on the floor and let the OS sort it out on exit[1] (I think the D compiler does this); in a multiple-pass batch process, make each pass litter its own room (arena, obstack, etc.) then demolish said room when done (GCC does this or at least did in the past). On the other hand, these may require rearranging the logic somewhat to fit them, so the question of how much rearrangement to tolerate still remains. And, well[4], /* * We divy out chunks of memory rather than call malloc each time so * we don't have to worry about leaking memory. It's probably * not a big deal if all this memory was wasted but if this ever * goes into a library that would probably not be a good ide