3 ms·

C11 has aligned_alloc, which is more standard than posix_memalign, but there is no standard "aligned_realloc". There is no default alignment if all the functio

C11 has aligned_alloc, which is more standard than posix_memalign, but there is no standard "aligned_realloc". There is no default alignment if all the functions of the allocator take it as a parameter, but it is reasonable for an allocator implementation to be optimized for a particular alignment requirement such as _Alignof(max_align_t).

eqvinox 3y ago
> C11 has aligned_alloc, which is more standard than posix_memalign, I don't have data on this but I feel that posix_memalign might be more widely supported than aligned_alloc. Then again C11 is 12 years old now so hopefully this changed. > There is no default alignment if all the functions of the allocator take it as a parameter, I would assume you can pass 0 as the requested alignment, which makes the allocator use some default. If the allocator always requires an alignment value, it becomes a serious pain to go through all allocations and figure out a reasonable alignment value. Especially since in most cases you really don't care.
- el_pollo_diablo 3y ago
  > I don't have data on this but I feel that posix_memalign might be more widely supported than aligned_alloc. Possibly. IIRC Microsoft's CRT does not support aligned_alloc() because their implementation of free() cannot deal with extended alignment requirements, so they have separate functions for aligned (de)allocation. To be fair, they probably do not support posix_memalign() either. > it becomes a serious pain to go through all allocations and figure out a reasonable alignment value Sure, you can pass _Alignof(max_align_t) in almost all cases, or have generic (= not reimplemented by each allocator) convenience wrapper functions that do that for you. If you want to pass the least restrictive alignment in all cases, you can enlist the help of a macro, but this is a bit more awkward. For instance: #define ALLOC(ptr, size) ((ptr) = alloc(_Alignof(typeof(*(ptr))), (size))) foo_t *p; ALLOC(p, 42 * sizeof *p); (Note that this uses the typeof() operator, which should become standard with C23.)
  - tlb 3y ago
    max_align_t is only the max for scalar types, typically 8 or 16 bytes. But often math-intensive code wants 16 or 32 byte alignment for float arrays, to enable SIMD operations.
    - el_pollo_diablo 3y ago
      > max_align_t is only the max for scalar types, typically 8 or 16 bytes. But often math-intensive code wants 16 or 32 byte alignment for float arrays, to enable SIMD operations. Indeed, but _Alignof(max_align_t) is a good compromise for a default alignment requirement in an allocator interface, which is what eqvinox calls for. Standard C does exactly that: malloc(), realloc(), and calloc() promise that they satisfy _Alignof(max_align_t), but nothing stricter. To reach for extended alignment requirements, your only standard tool is aligned_alloc().

eqvinox 3y ago

> C11 has aligned_alloc, which is more standard than posix_memalign, I don't have data on this but I feel that posix_memalign might be more widely supported than aligned_alloc. Then again C11 is 12 years old now so hopefully this changed. > There is no default alignment if all the functions of the allocator take it as a parameter, I would assume you can pass 0 as the requested alignment, which makes the allocator use some default. If the allocator always requires an alignment value, it becomes a serious pain to go through all allocations and figure out a reasonable alignment value. Especially since in most cases you really don't care.

el_pollo_diablo 3y ago
> I don't have data on this but I feel that posix_memalign might be more widely supported than aligned_alloc. Possibly. IIRC Microsoft's CRT does not support aligned_alloc() because their implementation of free() cannot deal with extended alignment requirements, so they have separate functions for aligned (de)allocation. To be fair, they probably do not support posix_memalign() either. > it becomes a serious pain to go through all allocations and figure out a reasonable alignment value Sure, you can pass _Alignof(max_align_t) in almost all cases, or have generic (= not reimplemented by each allocator) convenience wrapper functions that do that for you. If you want to pass the least restrictive alignment in all cases, you can enlist the help of a macro, but this is a bit more awkward. For instance: #define ALLOC(ptr, size) ((ptr) = alloc(_Alignof(typeof(*(ptr))), (size))) foo_t *p; ALLOC(p, 42 * sizeof *p); (Note that this uses the typeof() operator, which should become standard with C23.)
- tlb 3y ago
  max_align_t is only the max for scalar types, typically 8 or 16 bytes. But often math-intensive code wants 16 or 32 byte alignment for float arrays, to enable SIMD operations.
  - el_pollo_diablo 3y ago
    > max_align_t is only the max for scalar types, typically 8 or 16 bytes. But often math-intensive code wants 16 or 32 byte alignment for float arrays, to enable SIMD operations. Indeed, but _Alignof(max_align_t) is a good compromise for a default alignment requirement in an allocator interface, which is what eqvinox calls for. Standard C does exactly that: malloc(), realloc(), and calloc() promise that they satisfy _Alignof(max_align_t), but nothing stricter. To reach for extended alignment requirements, your only standard tool is aligned_alloc().