4 ms·
Just another idea for use after free: What If we combined the 'non-repeating' malloc idea with 128-bit uuids? malloc would just return a 128-bit uuid, and to
by randyrand 4y ago
Just another idea for use after free:
What If we combined the 'non-repeating' malloc idea with 128-bit uuids?
malloc would just return a 128-bit uuid, and to get to the data ptr you'd need to consult a hash table.
dataPtrArr[hash(uuid)].dataPtr = dataPtr
We'd check if it's been freed by checking:
dataPtrArr[hash(uuid)].uuid == uuid
- pjmlp 4y agoAt which point is much simpler to introduce automatic memory management in some form. That solution is basically how platforms like Psion or Symbian used handles due to memory constraints.
- randyrand 4y agoIMO this is still simpler than automatic memory management, and the runtime costs are mostly fixed and predictable. You also don't need to worry about ref cycles or GC pauses.
- pjmlp 4y agoAssuming the mythical existence of the perfect developer that nevers does mistakes which handle to use, which certainly wasn't the case on Psion or Symbian projects.
- flohofwoe 4y agoAt that point it's better to use 'tagged index handles', but IMHO that's outside the scope of the language (but maybe an option for the stdlib): https://floooh.github.io/2018/06/17/handles-vs-pointers.html https://floooh.github.io/2018/06/17/handles-vs-pointers.html (but for this an "auto-decaying pointer" would be nice which cannot be stored outside the stack and cannot be "carried across" function calls.
- randyrand 4y agoNice article. Similar idea ofc. Yes, that design could work tho all objects per pool must be the same size. Not sure how that would be better.