How about using APR_ALIGN_DEFAULT instead of computing grain?
Sure - anything to make sure that the allocation is always a multiple of 8 would do :)..
Question : Is 8 sufficient ?. What if there is a "long double" in some data structure - where the allocation would change again.. The apr_rmm headers are probably okay - the compiler always allocates 16 bytes.
OR, is it better to have the value '8' in APR_ALIGN_DEFAULT to be determined during the configure phase ?.
It's not necessarily about the long double (or the largest element in a structure) - AIUI, it's that the base pointer needs to be aligned by 8 rather than 4. I don't believe it has anything to do with the internal structure. Since all of the pool allocated memory is currently aligned by 8, I've got to imagine that's sufficient. If it weren't, then you'd see a SIGBUS on all memory operations. If we had to grow the alignment for a specific platform, we'd do it in APR_ALIGN_DEFAULT. So, that seems to me to be the right strategy for apr_rmm.
Perhaps someone else can shed some light on this... -- justin
