Can we replace the malloc with our custom one (Like idk: gcmalloc, garbage-collected malloc) which keeps track of mallocs in a linked-list and free them all at once at the end of compilation?

awesome! totally agree.

Not try to butt in to much, but wouldn't doing that be kind of pointless? All allocations are already cleaned at the end of execution by the OS. The point of detecting memory leaks is more so you can free memory at appropriate times so your program itself has more memory to work with. Dropping everything in a custom allocator doesn't really fix the major problems with the leak, it just hides it from the leak analyzer.

But love looking at the project so far. It'll be interesting to see how it progresses.

Not try to butt in to much, but wouldn't doing that be kind of pointless? All allocations are already cleaned at the end of execution by the OS. The point of detecting memory leaks is more so you can free memory at appropriate times so your program itself has more memory to work with. Dropping everything in a custom allocator doesn't really fix the major problems with the leak, it just hides it from the leak analyzer.

But love looking at the project so far. It'll be interesting to see how it progresses.

Tnx!

Imagine the compiler takes several files as input, and the allocations are all freed when we go compiling the next file. It wouldn't be pointless anymore, right?

Tnx!

Imagine the compiler takes several files as input, and the allocations are all freed when we go compiling the next file. It wouldn't be pointless anymore, right?

That's fair, in that case I could see it being more useful. Something more akin to a frame allocator used in games. I don't know what the plan is around multi-file compilation is though so I can't say anything concrete. Having an allocator that just holds onto everything till the end of a compilation however could cause congestion and slow down multi-threaded compilation in process (if implemented) or out of process (like cmake.)

Note: If everything is going to remain single threaded, then everything below might not be useful.

But at that point it's more about trade-offs since calling the system allocator can be slow. As before not the decision maker, but I think I would do the gcmalloc with a builtin leak reporting system (only enabled in debug?) and maybe something like a ref counted pointer. That would still allow you to fix or reduce leaks over time, both the simple and complex ones. That could also allow you to do a page based allocation so when a page is completely cleared it could be reused or freed to the system. That could allow you to fix leaks while still allowing you to just wipe out everything per compilation in the short term.

That might be a little complex though depending on the scope of the project.

That might be a little complex though depending on the scope of the project.

Another option is to just ignore the leaks and keep it simple, since this is just an educational compiler hah