From what I can tell: that while this memory-management strategy can stop a program from seg-faulting or from executing remote code, the style of programming is the same as with `malloc` and `free`. You still have to `alloc_texture()` and `free_texture()` in your code even if those functions return a handle instead of a raw pointer.

Some observations about the strategy based on the article:

  - It does *not* prevent memory leaks. It uses fixed size arrays, so once you allocate more memory
  than there is room in the array, then the program has to exit.
  - It does not prevent use after free. It just makes it easier to detect when this has happened.

This could make debugging easier in some situations. I do wonder though how it interacts with code analyzers.

Also this could work in any language. I wonder if it's common in game development for Android, because of Java and garbage collection spikes.

Oh, and another observation: I think this strategy is fully compatible with RAII and smart pointers. Smart pointers are implemented using malloc/free, and this strategy is isomorphic to malloc/free, so combining them should work fine.