IXP_PU8(3)

💅 IXP_PU8(3) — pack/unpack unsigned ints, but make it cute 💅

okay so you opened IXP_PU8(3) from the Library Functions Manual, and honestly? iconic. this is the libixp page for the little unsigned-integer pack/unpack girlies, and they are lowkey doing a lot of work. no cap. ✨

🎀 NAME 🎀

ixp_pu8, ixp_pu16, ixp_pu32, ixp_pu64

so yes bestie, it's a whole squad: ixp_pu8, ixp_pu16, ixp_pu32, and ixp_pu64. they all live here together. 🫶

🦋 SYNOPSIS 🦋

#include <ixp.h>

void ixp_pu8(IxpMsg *msg, uint8_t *val);

void ixp_pu16(IxpMsg *msg, uint16_t *val);

void ixp_pu32(IxpMsg *msg, uint32_t *val);

void ixp_pu64(IxpMsg *msg, uint64_t *val);

see? four functions, four sizes, same energy. main character formatting. 💅

💖 DESCRIPTION 💖

these functions pack or unpack an unsigned integer of the specified size. that's the whole vibe: pick your size, call your function, let it cook. 🔥

if msg->mode is MsgPack, the value pointed to by val is packed into the buffer at msg->pos. yes, literally packed in there. 🎀

if msg->mode is MsgUnpack, the packed value at msg->pos is loaded into the location pointed to by val. unpacking era. ✨

in both cases, msg->pos is advanced by the number of bytes read or written. so msg->pos is always moving forward like it's got somewhere to be. 🦋

okay this part is important, bestie: if the call would advance msg->pos beyond msg->end, msg->pos is advanced, but nothing is modified. so the position moves, but the data does not. it's giving "walked in, changed nothing, left." 💀 don't forget that detail, fr fr.

🔥 SEE ALSO 🔥

• IxpMsg(3) — go read that one too, iykyk 👑

made with pure libixp Manual energy, dated 2012 Dec, and yes this is still IXP_PU8(3) — byeee, mwah 💋🌈