GELF_GETCAP(3)

πŸ“¦ version 15.1, in freebsd 14.5, freebsd 15.1, nixpkgs unstable

πŸ’… GELF_GETCAP(3) πŸ’…

ok so bestie, this is a page from the Library Functions Manual for gelf_getcap and gelf_update_cap, and it lives in the ELF Access Library (libelf, -lelf) β€” yes the linker flag is literally -lelf, slay. πŸŽ€


✨ NAME ✨

gelf_getcap, gelf_update_cap β€” read and update ELF capability information. that's the whole vibe. πŸ’–


πŸ“š LIBRARY πŸ“š

ELF Access Library (libelf, -lelf) β€” link it and it's yours, no cap. 🫢


🧚 SYNOPSIS 🧚

#include <gelf.h>

GElf_Cap *
gelf_getcap(Elf_Data *data, int ndx, GElf_Cap *cap);

int
gelf_update_cap(Elf_Data *data, int ndx, GElf_Cap *cap);

like, look at it. two little functions. absolutely iconic. ⭐


🌸 DESCRIPTION 🌸

okay so these are the convenience functions β€” you know, the ones that save you from doing the class-dependent thing by hand β€” and they're here to retrieve and update class-dependent Elf32_Cap or Elf64_Cap information. yes, class-dependent, meaning 32-bit vs 64-bit, iykyk. πŸ”₯

Argument data is an Elf_Data descriptor, and it needs to be associated with a section of type SHT_SUNW_cap. that's the vibe check it has to pass, fr fr. Argument ndx is the index of the entry you're retrieving or updating β€” like, which one in the lineup. and the class-independent GElf_Cap structure? that's described over in gelf(3), go peek. πŸ‘‘

Function gelf_getcap() retrieves the class-dependent entry at index ndx in the data buffer data, and copies it to the destination pointed to by argument cap β€” but only after translation to class-independent form. so it does the glow-up for you. πŸ’…

Function gelf_update_cap() goes the other way around: it converts the class-independent entry pointed to by argument cap to class-dependent form, and writes it to the entry at index ndx in the data buffer described by argument data. and here's the thing, bestie β€” gelf_update_cap() signals an error if any of the values in the class-independent representation exceeds the representable limits of the target type. so if your number is too big for the target? nope. error. it will not be squeezing into that outfit. 😭


πŸ¦‹ RETURN VALUES πŸ¦‹

  • Function gelf_getcap() returns the value of argument cap if everything's good, or NULL if it's not. πŸ’€
  • Function gelf_update_cap() returns a non-zero value on success, or zero if something went wrong. simple as that. ✨

πŸ“ ERRORS πŸ“

these functions may fail with the following errors β€” cop the list:

  • [ELF_E_ARGUMENT] β€” Arguments data or cap were NULL. like, you gave me nothing, bestie.
  • [ELF_E_ARGUMENT] β€” Argument ndx was less than zero or larger than the number of entries in the data descriptor. out of bounds, literally.
  • [ELF_E_ARGUMENT] β€” Data descriptor data was not associated with a section of type SHT_SUNW_cap. wrong section, wrong crowd. πŸ™ˆ
  • [ELF_E_RANGE] β€” A value was not representable in the target type. too much for the target to hold, periodt.
  • [ELF_E_VERSION] β€” The Elf_Data descriptor denoted by argument data is associated with an ELF object with an unsupported version. the version check said no. 🧚

πŸ’œ SEE ALSO πŸ’œ

elf(3), elf_getdata(3), elf_getscn(3), gelf(3) β€” go read those next, they're the supporting cast and they ate. πŸ‘‘


ok that's the whole page, no notes. go forth and handle your capability entries with main character energy. 🌈

and that's a wrap, bestie β€” this one's from the Debian edition, dated April 22, 2019, and the page itself is GELF_GETCAP(3). that's the source, the version, and the date, all folded into this cute little sign-off so nothing gets lost. πŸŽ€πŸ’–

πŸ“¦ where this page comes from