Hi Chris,

I really enjoyed your article on classic data structure strategies
using arenas (Jan 2025, https://nullprogram.com/blog/2025/01/19/)

Fantastic write-up, I love your "Arena-oriented" programming xD

About your `push_()` function in particular,

When you grow the slice:
    void *copy = alloc(a, cap, size, align);
    alloc(a, extend, size, align);

Wouldn't the second alloc — the one just extending capacity —
be better off without reapplying alignment?

It's guaranteed to be immediately after the previous allocation,
this padding could create unnecessary fragmentation
or even break the contiguity that the next `push_()` checks for:
(`a->beg != data + cap*size`)

Wouldn't the pad, caused by the align, make it always reallocate?
Since due to the pad the condition will always fail?

Thanks for your work and the incredible design you share
It's inspiring to see your C code!

– Aleh

Astute observation, Aleh, you're right! When array element alignment is 
smaller than pointer alignment, and its storage was the most recent arena 
allocation, but does not end on a pointer-aligned address, the arena will 
allocate slightly too much as alignment padding, fragmenting the arena. A 
subsequent growth will not happen in place despite being possible. It will 
happen repeatedly if the capacity is not a power of two.

I've updated the article, updating the code and adding a note. Thanks for 
pointing this out and letting me know!

On Mon, Apr 07, 2025 at 11:54:25AM -0400, Christopher Wellons wrote:
> Astute observation, Aleh, you're right! When array element alignment is
> smaller than pointer alignment, and its storage was the most recent arena
> allocation, but does not end on a pointer-aligned address, the arena will
> allocate slightly too much as alignment padding, fragmenting the arena. A
> subsequent growth will not happen in place despite being possible. It will
> happen repeatedly if the capacity is not a power of two.

This would've been a non-issue if the macro simply passed the actual
alignment over to the function, right? One more reason I prefer doing
`_Alignof(__typeof__(expr))` to work around the standard `_Alignof`
defect.

- NRK

Thanks for the reminder, NRK! You're right, this was caused by the alignof 
workaround. After our discussion I intended to note your idea, but forgot. 
I just pushed that update to the article.

Ha! An honor to have a update in the blog of the greatest C Master xD

Great solution NRK, using alignof typeof,supported in gcc/clang/tcc & C23
makes it correct by default - Greatly improving it's "DX"

- Aleh

Em seg., 7 de abr. de 2025 às 14:55, Christopher Wellons
<wellons@nullprogram.com> escreveu:
>
> Thanks for the reminder, NRK! You're right, this was caused by the alignof
> workaround. After our discussion I intended to note your idea, but forgot.
> I just pushed that update to the article.