I hate that very often my first reaction to Show HN posts like this is to cynically look for signs of blatant AI code use.

I don't think that's the case here though.

Looks nice! Though I have to say, you should probably avoid sbreak even for small allocations -- obviously it's slow, but even beyond that you have to deal with the fact that it's essentially a global singleton and introduces a lot of subtle failure cases you might not think of + which you can't really solve anyways. It's better to mmap out some chunk of memory and sub-allocate it out yourself.

That project structure is reminding me of claude.

Why redeclare the function signatures in allocator.h[0] when they must match what is already defined by the C standard?

Since this is all allocator.h[0] contains aside from other include statements, why have allocator.h at all?

0 - https://github.com/t9nzin/memory/blob/main/include/allocator...

  #include <stddef.h>
  #include <stdbool.h>
  
  void *malloc(size_t size);
  void *calloc(size_t n, size_t size);
  void *realloc(void *ptr, size_t size);
  void free(void *ptr);

I always like me some memory allocator blog/code. Two links in the context of gamedev below, in case you or anyone else is interested.

https://screwjankgames.github.io/engine%20programming/2020/0...

https://www.bytesbeneath.com/p/the-arena-custom-memory-alloc...

I also don't know how much we want to butcher this blog post, but:

> RAM is fundamentally a giant array of bytes, where each byte has a unique address. However, CPUs don’t fetch data one byte at a time. They read and write memory in fixed-size chunks called words which are typically 4 bytes on 32-bit systems or 8 bytes on 64-bit systems.

CPUs these days fetch entire cache lines. Memory is also split into banks. There are many more details involved, and it is viewing memory as a giant array of bytes that is fundamentally broken. It's a useful abstraction up until some point, but it breaks apart once you analyze performance. This part of the blog didn't seem very accurate.

One line: bump sbrk(). Done.

No need to free in short living processes

This looked nice and simple, appreciated!

A couple of minor C points:

- The code seems to completely lack use of `static` for things that should be local to the implementation, such as `META_SIZE`, `find_free_block()` and others.

- The header includes `<stdbool.h>` but the interface doesn't use it so it could be included in the C file instead (which, in fact, it is!).

- Could do with more `const` for clarity, but that is quite personal.

- Interesting to use explicit comparison to check for integers being zero, but treat pointers being NULL as implicit boolean. I prefer comparing in both cases.

This is not a good idea. You're venturing in the unspecified/non-portable behavior territory.

https://pubs.opengroup.org/onlinepubs/7908799/xsh/brk.html

> The behaviour of brk() and sbrk() is unspecified if an application also uses any other memory functions (such as malloc(), mmap(), free()). Other functions may use these other memory functions silently.

Well done!

My remarks:

1) in calloc() you correctly check size*n against SIZE_MAX, but in multiple other spots you don't check size+META_SIZE.

2) the field is_mmap is useless: it can be replaced by (size>=MMAP_THRESHOLD) practically everywhere. The only corner case where this doesn't work is a large block initially backed by mmap() that's then shrunk via realloc() to under the threshold. But realloc() has other inconsistencies anyway, see next point.

3) realloc() shows the signs of a refactoring gone wild. The first if on block->size lacks a test on is_mmap, as split_block() doesn't seem to do the right thing with mmapped blocks...

4) free_list does not in fact track free nodes, as its name suggests, but all nodes, whether they are free or not. Wouldn't it be better to add a node to the list only when it's freed? I leave to you to iron out all the corner cases!