lsm_block...ord_alloc(3)

✨ NAME ✨

lsm_block_range_record_alloc — bestie, this is the one that hands you memory for a lsm_block_range record 💖

So like, this page lives in the Libstoragemgmt C API Manual (section 3, for all my fellow library-function girlies 🎀).

---

🌸 SYNOPSIS 🌸

lsm_block_range * lsm_block_range_record_alloc (uint64_t source_start,
       uint64_t dest_start, uint64_t block_count);

---

🦋 ARGUMENTS 🦋

• source_start — the start block of the replication source. Like, where the tea originates 👑
• dest_start — the start block of the replication destination. Where it's headed, main character energy ✨
• block_count — how many blocks this block range is holding down. The headcount, fr fr 🔢

---

💅 VERSION 💅

1.0 — iconic from day one, no cap ⭐

---

🌈 DESCRIPTION 🌈

Okay so here's the vibe: this function allocates memory for the lsm_block_range opaque data type, and that memory is gonna store a block range. That's it, that's the whole job, and it does it beautifully 🫶

Not me reminding you that opaque means you don't get to peek inside — it's giving mysterious, it's giving ✨enigma✨, just let it do its thing.

---

🍓 RETURN 🍓

You get back a pointer to lsm_block_range. Slay 💅

But bestie, listen — it returns NULL on memory allocation failure or on an illegal argument. Both of those are valid reasons to be sad 😭

And when you're done with it? You must free it with lsm_block_range_record_free. Leaving it hanging is NOT the move, that's a leak and leaks are 💀

---

That's the whole page, periodt. This gem is from the <strong>Libstoragemgmt C API Manual</strong>, version date <strong>February 2026</strong>, and yeah — the footer does that cute little truncated thing, <code>lsm_block...ord_alloc(3)</code>, because even manpage footers gotta keep it mysterious. Bye bestie, go allocate responsibly 💖✨🎀