3 ms·

A good API can use only a single ABI-level function, but it needs more parameters than that. I imagine 4 arguments, at least 2 of which are themselves composite

by o11c 3y ago

A good API can use only a single ABI-level function, but it needs more parameters than that. I imagine 4 arguments, at least 2 of which are themselves composite: auto utopia_alloc(Allocation, AlignAndSkew, Size, Flags) -> Allocation; That said, while "one function" makes interposing easy, it does mean significant branching cost compared to single functions. There's probably a way to get the best of both worlds (support several functions in the ABI, but forward them all to `utopia_alloc` if interposed). more details at https://gist.github.com/o11c/6b08643335388bbab0228db763f99219#file-memory-allocation-api-md https://gist.github.com/o11c/6b08643335388bbab0228db763f9921... Aside: I really hate how the nullprogram site linked seems allergic to type-safety.

lifthrasiir 3y ago
Oh that is indeed a good list, you should submit that gist independently. That said, I believe alignments should be a suggestion and not a mandatory request, mainly because the library can fix a bad alignment by overallocation. Charles Bloom has suggested a similar thing in the past [1]. Out of possible flags the zeroing flag is probably the most used and possibly only flag needed for library uses; others are also important but only a small number of libraries will ever want them. Again, a failure to do so should ideally be somehow detected and fixed, but that detection can't be actually checking for non-zeros, so the provided function should somehow return whether the memory was actually zeroed or not. (I also share the same concern about the site, by the way.) [1] https://cbloomrants.blogspot.com/2015/09/library-writing-realizations.html https://cbloomrants.blogspot.com/2015/09/library-writing-rea... (specifically the "Simplicity is better" point)
- o11c 3y ago
  Alignment has to be mandatory because otherwise `free` breaks.
  - lifthrasiir 3y ago
    I think you are imagining an aligned allocator out of an unaligned allocator, where the misalignment should be stored somewhere around the actual memory block, but if the main allocator itself is aware of aligned allocations it is not necessary. I can still imagine the case where allocation bins are structured by the allocation size and alignment size and an incorrect alignment will result in an incorrect bin, but such bins are only beneficial when the alignment itself is too large compared to allocation sizes, and I'm not sure who really wants them in the first place.
eqvinox 3y ago
> Aside: I really hate how the nullprogram site linked seems allergic to type-safety. +∞ to this. Considering the ecosystem limitations as they are, it's paramount to use every possible thing available to catch mistakes.
vitaminCPP 3y ago
> Aside: I really hate how the nullprogram site linked seems allergic to type-safety. Could you give us an example, I'm not sure what you refering to.

by o11c 3y ago

lifthrasiir 3y ago

Oh that is indeed a good list, you should submit that gist independently. That said, I believe alignments should be a suggestion and not a mandatory request, mainly because the library can fix a bad alignment by overallocation. Charles Bloom has suggested a similar thing in the past [1]. Out of possible flags the zeroing flag is probably the most used and possibly only flag needed for library uses; others are also important but only a small number of libraries will ever want them. Again, a failure to do so should ideally be somehow detected and fixed, but that detection can't be actually checking for non-zeros, so the provided function should somehow return whether the memory was actually zeroed or not. (I also share the same concern about the site, by the way.) [1] https://cbloomrants.blogspot.com/2015/09/library-writing-realizations.html https://cbloomrants.blogspot.com/2015/09/library-writing-rea... (specifically the "Simplicity is better" point)

o11c 3y ago
Alignment has to be mandatory because otherwise `free` breaks.
- lifthrasiir 3y ago
  I think you are imagining an aligned allocator out of an unaligned allocator, where the misalignment should be stored somewhere around the actual memory block, but if the main allocator itself is aware of aligned allocations it is not necessary. I can still imagine the case where allocation bins are structured by the allocation size and alignment size and an incorrect alignment will result in an incorrect bin, but such bins are only beneficial when the alignment itself is too large compared to allocation sizes, and I'm not sure who really wants them in the first place.

eqvinox 3y ago

> Aside: I really hate how the nullprogram site linked seems allergic to type-safety. +∞ to this. Considering the ecosystem limitations as they are, it's paramount to use every possible thing available to catch mistakes.

vitaminCPP 3y ago

> Aside: I really hate how the nullprogram site linked seems allergic to type-safety. Could you give us an example, I'm not sure what you refering to.