PMFREERESULT(3)

💖 PMFREERESULT(3) 💖

okay so bestie, welcome to the Library Functions Manual page for pmFreeResult — this is the one where we clean up after ourselves, and honestly? iconic behavior. 🧹✨

---

✨ NAME ✨

pmFreeResult — release storage allocated for performance metrics values 🫶

---

🌸 C SYNOPSIS 🌸

#include <pcp/pmapi.h>

void pmFreeResult(pmResult *result);

cc ... -lpcp

---

💅 DESCRIPTION 💅

So the variable sized results you get back from pmFetch(3)? They're allocated down below the Performance Metrics Application Programming Interface (PMAPI) using a combo of dynamic allocation (aka malloc(3)) and some specialized allocation strategies. it's giving ✨layered✨

When your app is done looking at that pmResult structure — like, no longer requires access to it, periodt — you call pmFreeResult to release the storage that pmFetch(3) previously allocated for result. that's the whole job. bestie job. 👑

🚨 NO CAP, LISTEN UP: under no circumstances should an application use free(result) to release storage previously allocated for a pmResult by pmFetch(3). do not do it. not even once. the malloc/free duo does not understand what's going on in there and it will not end cute. 💀

---

🌈 COMPATIBILITY 🌈

okay history lesson, stay with me 🦋

Before PCP 7.0, the timestamp field in the pmResult struct was a struct timeval. To support the PMAPI transition, the old interface and semantics can still be used — but only if applications are recompiled with -DPMAPI_VERSION=2. so like, retro mode, activated manually, iykyk.

Also, for a time in PCP 6.x there was a routine with the same semantics as the current pmFreeResult called pmFreeHighResResult. It's deprecated now bestie, and compile-time support for pmFreeHighResResult will be removed in a future release. so like… don't get attached. 😭

---

👀 SEE ALSO 👀

• PMAPI(3)
• malloc(3)
• pmFetch(3)

---

and that's the page!! 💖 brought to you by Performance Co-Pilot, PCP, and this very PMFREERESULT(3) footer moment — mwah, go free your results responsibly, love u bye 🎀🌸