20

There exist several aligned versions of the venerable malloc(), e.g.:

#include <stdlib.h>
int posix_memalign(void **memptr, size_t alignment, size_t size);
void *aligned_alloc(size_t alignment, size_t size);

#include <malloc.h>
void *memalign(size_t alignment, size_t size);

(originating in POSIX, glibc and Linux libc respectively). But - I can't seem to find any mention of a version of realloc() which supports alignment. Has it really never been implemented? It seems pretty trivial to combine the functionality of non-aligned realloc() with the search for an aligned chunk of memory in the aligned malloc() variants.

Related:

Does realloc keep the memory alignment of posix_memalign?

einpoklum
  • 118,144
  • 57
  • 340
  • 684
  • Yes. There is no for many reasons. One is that the alligned allocated functions do not save information about the data size of the alligned block and no copy of data is possible. It was left to the application developer. There were many reasons for it, very actively discussed many years ago - see the appropriate mailing list archives for details – 0___________ Aug 04 '17 at 10:33
  • 3
    @PeterJ: Are you saying the aligned allocation functions save _less_ information than what `malloc()` saves? I highly doubt it... anyway, if you can flesh this out some more, preferable with a link to some of that discussion, please post an answer. – einpoklum Aug 04 '17 at 10:39
  • Not less. The topic is too complicated for the forum. Browse the mailing list archives for explanation. – 0___________ Aug 04 '17 at 11:02
  • 5
    @PeterJ: _Which_ list though?... – einpoklum Aug 04 '17 at 11:04
  • @einpoklum I would expect this to be around in the posix / iso-c mailing list archive. This is a guess - but I'll check in the evening (GMT) – Alexander Oh Aug 06 '17 at 13:09
  • *It seems pretty trivial to combine the functionality of non-aligned `realloc()` with the search for an aligned chunk of memory in the aligned `malloc()` variants.* And **that** would be a very simple reason for not implementing it. It's "pretty trivial". – Andrew Henle Aug 06 '17 at 20:50
  • 2
    @AndrewHenle: Pretty trivial when you're on the inside of the allocator, not on the outside. – einpoklum Aug 06 '17 at 21:05
  • 1
    @TonyTannous: Thanks for the bounty, friend :-) – einpoklum Aug 06 '17 at 21:07
  • 1
    @TonyTannous: I just asked [this](https://meta.stackexchange.com/q/299376/196834) – einpoklum Aug 06 '17 at 21:12
  • @einpoklum *Pretty trivial when you're on the inside of the allocator, not on the outside.* I'd consider a function that consists of little more than calls such as `posix_memalign()`, `memcpy()`, `free()`, and a bit of error checking pretty trivial even from the outside of the allocator. – Andrew Henle Aug 06 '17 at 22:13
  • For (large) aligned memory requirements, applications normally use anonymous memory maps via `mmap()`. Even though they aren't standard C or even POSIX, they are supported by most systems (excluding Windows, of course). (For large amounts of memory, allocating a copy at the same time, for @AndrewHenle's workaround, may not be possible at all. Consider e.g. a 2GB+ object on a 32-bit system.) – Nominal Animal Aug 06 '17 at 23:15

1 Answers1

7

Aligned realloc is only implemented in Microsoft with the _aligned_realloc function. There is no POSIX version defined and no implementation in Linux. I never understood why though, because it does not seem so complicated to code in glibc. I think it's a matter of time before someone implement it considering the advent of wide SIMD instructions.

At the moment, just allocate a new block of aligned memory, copy the content and free the old pointer. This should not slow down your application anyway.

yakoudbz
  • 903
  • 1
  • 6
  • 14