On Mon, Mar 27, 2017 at 3:55 PM, Ivan Zhakov <[email protected]> wrote: > On 24 March 2017 at 00:34, <[email protected]> wrote: >> + >> +/** >> + * Return the aligned (round up) size that an allocator would use for >> + * the given size. >> + * @param size The size to align >> + * @return The aligned size (or zero on apr_size_t overflow) >> + */ >> +APR_DECLARE(apr_size_t) apr_allocator_align(apr_size_t size); > What is the purpose of this API? Currently caller may use > apr_memnode_t.endp to find actually allocated memory size.
The purpose is to get this size before allocating any memory. It is (newly) used in APR by apr_bucket_alloc_aligned_floor (itself used by apr_bucket_file_set_buf_size), where the purpose is to take into account and be precise with the overhead of the (bucket_)allocator(s), and avoid over-allocating (wasted) memory. > > Anyway I think it maybe worth to add apr_allocator_t argument to > apr_allocator_align() function even currently allocation alignment is > the same for all allocators. I see your point, but since there is no way to do this yet and that'd require another API change, maybe we could do this at that time? If you are concerned about the current name which would better fit an allocator argument, let's use apr_allocator_default_align() for now... or e.g. apr_allocator_align_of() later ;) Hmm, this makes me think that if apr_allocator_align() need an alloctor, apr_bucket_alloc_aligned_floor() needs a bucket_alloc too, and both functions may be less useful (or easy to use) if they require the allocator the memory will finally be allocated on (say apr_allocator_align() has to be used at the init time of an application where the runtime allocator is not created yet). Also why would one want a different allocator alignment since (s)he can apr_allocator_alloc() any size in the first place? The alignment looks more like a property of the system than the allocator itself for me...
