[libc-commits] [libc] [libc] Add aligned_alloc (PR #96586)

Paul Kirth via libc-commits libc-commits at lists.llvm.org
Tue Jun 25 10:03:33 PDT 2024


================
@@ -357,6 +392,58 @@ void Block<OffsetType, kAlign>::free(Block *&block) {
   merge_next(block);
 }
 
+template <typename OffsetType, size_t kAlign>
+bool Block<OffsetType, kAlign>::can_allocate(size_t alignment,
+                                             size_t size) const {
+  if (usable_space_is_aligned(alignment) && inner_size() >= size)
+    return true; // Size and alignment constraints met.
+
+  // Either the alignment isn't met or we don't have enough size.
+  // If we don't meet alignment, we can always adjust such that we do meet the
+  // alignment. If we meet the alignment but just don't have enough size. This
+  // check will fail anyway.
+  size_t adjustment = extra_space_for_adjustment(alignment);
+  if (inner_size() >= size + adjustment)
+    return true;
+
+  return false;
+}
+
+template <typename OffsetType, size_t kAlign>
+void Block<OffsetType, kAlign>::allocate(Block *&block, size_t alignment,
+                                         size_t size, Block *&new_prev,
+                                         Block *&new_next) {
----------------
ilovepi wrote:

do you think this API would make more sense if you passed in a struct instead of the pointer references?
```suggestion
struct block_info{ Block* block, Block* prev, Block* next};
void Block<OffsetType, kAlign>::allocate(BlockInfo &block_info, size_t alignment,
                                         size_t size) {
```
I find the mutable references to pointers to make for an odd API, and this reads a bit more naturally  to me.

Feel free to disregard this though, since this comes down to style, and it could be this API is this shape for another reason.

https://github.com/llvm/llvm-project/pull/96586


More information about the libc-commits mailing list