I think current AVS+ alignement is 32 [EDIT: Actually 64] (avs std 16) (probably thinking about 64 next, or whatever eg AVX2/later requires).
EDIT: As shown above, having v2.58 Version 3 header Baked Code, is quite handy to have [the raw cookie dough code tells you very little].
EDIT: Below some meanderings, no idea why I just wrote it.
Code:
malloc/new
Library writers long ago found that it is inefficient to allocate small blocks of memory, as that produces memory fragmentation, and so slower finding of suitable sized mem block.
So, was usual in C library, when user requested block size of eg 1 bytes, to carve off 8 bytes, and hand pointer back to user. Only 1 byte of this block belonged to the user,
but there would be no error encountered if user used up to 8 bytes as carved out from free memory lists.
Memory size returned was rounded up to a multiple of 8 bytes, so requesting 1 to 8, would carve out 8 bytes, 9 to 16, 16 bytes etc.
An additional bonus of this round up to 8 bytes, was that the memory block when free'ed, there was always enough room in that block to create a link in a linked list, for use in the
free memory list arrangement. The free memory block kept track of 'itself', without any additional overhead, and mem fragmentation was much less and also faster to find block of
sufficient size. [link list struct would hold 32 bit int size of mem block, and 32 bit pointer to next link in list, both 4 byte values on 32 bit system].
Above round up to 8 bytes also enabled the ANSI spec that malloc() returns a pointer to mem bock that is castable to a memory block structure of any type [or words something like that],
ie, some structures need be located on a memory boundary of maybe 2 bytes, 4 bytes or 8 bytes. If the initial heap base pointer is rounded to multiple of 8 bytes, and all mem blocks are a multiple
of 8 bytes, so all malloc blocks will return a mem bufer on 8 byte boundary.
Unfortunately, above used to cause novice C proggers to cock up when allocating string buffers, for small strings (less than 8 chars), as there were no problems produced when forgetting
to add 1 bytes for the nul term sentinel (zero byte) at end of string. This due to habit of writing C examples using "fred" and "ted" sized strings.
Novice C proggers would get the impression that it was unnecessary to add that 1 extra byte for the nul term because they never experienced any errors,
but of course this is bad, and perhaps the hardest of all bugs to track down.
Imagine you created a DBase for some project, and that it held Name field, and Title field, and Address etc, but that in the title field, you forgot to add the 1 byte for nul term.
Your DBase might go on seemingly OK for 5 or more years without any trouble at all, then one day you get new accound created for title "Princess", exactly 8 bytes in length, but
requiring 9 bytes in total for the buffer. you ask for 8 bytes, and this time you actually need 9, kaboom!!!, you blast a byte that does not belong to you, belongs to some other
structure or maybe even a link in the free memory list. As you repeatedly save and load (at day end/start) the DBase, each and every time, the problem is likely to move about, causing
corruption in differeing parts of your DBase, and eventually it will be noticed and become a problem.
Where do you start to look for the problem ???, you got 5 years spare to keep tabs on your next newly created DBase?
Because of the C libs malloc/calloc/new etc optimisation stuff, you have to be paranoid about that 1 extra byte, and suggest always allocate string buffers via a single function
which auto adds the required extra nul term byte. [look up the non ANSI function 'strdup()' and knock it up yourself if not supplied with your compiler
[STRICT_ANSI (or whatever the define is) will exclude it even if it does exist in your compiler].
For x64, it is most likely [ie definite] that the 8 byte fragment size mentioned above will be 16 bytes, so if you request 1 bytes from malloc, you will actually get 16, making the
above mentioned failure to add 1 byte for nul term on string buffer, an even bigger problem for string buffer bug hunting.
Also, a little aside,
Some C docs for calloc() seem to have ommitted the fact that calloc will auto zero memory [where malloc does not], think maybe MicroSoft (or someone, forgot about this more than insignificant
fact and just missed it out), and everybody else copied the erroneous docs. Perhaps your compiler mentions this clearing of memory by calloc, perhaps not [somewhere about year 1992->2000, they all/many
[cross platform] seemed to have forgotten about it].