PCAP_DUMP_FTELL(3PCAP)

πŸ“¦
version 1.10.7 Β· 2 versions
  • 1.10.7 Β· alpine 3.22, alpine 3.23, alpine 3.24, centos-stream 10, centos-stream 9, debian bookworm, debian trixie, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, opensuse-leap 16.0, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking (latest)
  • 1.11.0 Β· arch rolling
, in alpine 3.22, alpine 3.23, alpine 3.24, centos-stream 10, centos-stream 9, debian bookworm, debian trixie, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, opensuse-leap 16.0, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

✨ PCAP_DUMP_FTELL πŸ’…

okay bestie, welcome to the libpcap manual page for pcap_dump_ftell and pcap_dump_ftell64 β€” the two functions that tell you where you're at in a savefile you're currently writing. yes, we're doing file offsets today and it's gonna be iconic πŸŽ€


🌸 NAME 🌸

pcap_dump_ftell, pcap_dump_ftell64 β€” get the current file offset for a savefile being written ✨

like, "how many bytes in are we rn" but for the file you're writing to instead of reading from. periodt.


πŸ¦‹ SYNOPSIS πŸ¦‹

#include <pcap/pcap.h>

long pcap_dump_ftell(pcap_dumper_t *p);
int64_t pcap_dump_ftell64(pcap_dumper_t *p);

literally just these two, both taking a pcap_dumper_t *p and both handing you back an offset. one's the little version and one's the big version, iykyk πŸ’œ


πŸ‘‘ DESCRIPTION πŸ‘‘

πŸ’– pcap_dump_ftell()

so pcap_dump_ftell() returns the current file position for the savefile β€” and that's literally the number of bytes written by pcap_dump_open(3PCAP) and pcap_dump(3PCAP). that's it, that's the whole vibe 🫢

on error it returns PCAP_ERROR. and here's the part you need to know, bestie, because it's giving ⚠️: if the current file position does not fit in a long, it will be truncated. no cap. this can happen on 32-bit UNIX-like systems with large file support and on Windows 😭 so like… big file, small long, sad girl hours.

🧚 pcap_dump_ftell64()

pcap_dump_ftell64() returns the current file position in an int64_t instead. so if file offsets that don't fit in a long but do fit in an int64_t are supported, this baby will return the file offset without truncation πŸ”₯ slay. she ate and left no crumbs.

and yep β€” PCAP_ERROR is returned on error here too. same energy, bigger container πŸ’…

so the whole tea is: pcap_dump_ftell() = long, maybe truncated; pcap_dump_ftell64() = int64_t, not truncated (when the platform supports offsets that big). both say PCAP_ERROR when things go wrong. choose accordingly πŸŽ€

🌈 BACKWARD COMPATIBILITY 🌈

the function pcap_dump_ftell64() became available in libpcap release 1.9.0 ⭐

in previous releases, there was no mechanism to obtain a file offset that is too large to fit in a long. πŸ’€ like, none. zero. the long was the whole world and the world had edges. so if you're targeting something ancient, keep that in mind, bestie πŸ™ˆ


πŸ“ SEE ALSO πŸ“

  • pcap(3PCAP)

go read the big one, it's the main character of this whole family πŸ‘‘


🌸✨ and that's the page, bestie! brought to you by PCAP_DUMP_FTELL(3PCAP), dated 25 July 2018 β€” mwah, love u, go write some packets πŸ’–πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from