zzip_disk_mmap(3)

πŸ“¦
version 0.13.72 Β· 2 versions
, in debian bookworm, ubuntu jammy, ubuntu noble

πŸ’– zzip_disk_mmap(3) β€” zziplib Function List πŸ’–

okay bestie, buckle up, this is the one where you take a plain old filehandle and turn it into a whole mmapped zip disk archive handle ✨ it's giving main character energy for real.


🌸 NAME 🌸

zzip_disk_mmap, zzip_disk_init, zzip_disk_new, zzip_disk_munmap, zzip_disk_open, zzip_disk_buffer, zzip_disk_close β€” turn a filehandle into a mmapped zip disk archive handle 🫢


✨ SYNOPSIS ✨

#include <zzip/mmapped.h>

zzip__new__ ZZIP_DISK *
zzip_disk_mmap(int fd)

int
zzip_disk_init(ZZIP_DISK * disk, void *buffer, zzip_size_t buflen)

zzip__new__ ZZIP_DISK *
zzip_disk_new(void)

int
zzip_disk_munmap(ZZIP_DISK * disk)

zzip__new__ ZZIP_DISK *
zzip_disk_open(char *filename)

zzip__new__ ZZIP_DISK *
zzip_disk_buffer(void *buffer, size_t buflen)
int
zzip_disk_close(ZZIP_DISK * disk)

πŸ’… DESCRIPTION πŸ’…

So zzip_disk_mmap takes the file-descriptor you hand it, peeks at how long the file actually is, and then calls the system mmap(2) to yeet it into main memory. And if that works? Congrats babes πŸŽ€ you get a brand-new allocated ZZIP_DISK* back, with disk->buffer pointing right at the mapview of the zipdisk content. iconic.

And just so we're clear β€” zzip_disk_mmap may return null on errors (errno). that's the vibe check.

The zzip_disk_init function does primary initialization of a disk-buffer struct. that's it, that's the job πŸ’œ

And zzip_disk_init always returns 0 as success. always. no drama, no notes.

The zzip_disk_new function allocates a new disk-buffer with malloc(3) 🌈

The zzip_disk_new function may return null on errors (errno). 😭

The zzip_disk_munmap function is the inverse of zzip_disk_mmap β€” it uses the system munmap(2) on the buffer area and free(3) on the ZZIP_DISK structure. it's the breakup era, everything gets released ✨

The zzip_disk_open function opens the given archive by name and turns the filehandle over to zzip_disk_mmap to bring it into main memory. And if it can't be mmap(2)'ed? no worries, we slurp the whole file into a newly malloc(2)'ed memory block instead πŸ“ only if that fails too do we return null. fr fr, two chances.

⚠️ lowkey important: since handling of disk->buffer is ambiguous it should not be snatched away please. hands off, bestie πŸ™ˆ

And yes β€” zzip_disk_open may return null on errors (errno).

The zzip_disk_buffer function will attach a buffer with a zip image that was acquired from another source than a file. And heads up: if zzip_disk_mmap fails then zzip_disk_open will fall back and try to read the full file to memory, wrapping a ZZIP_DISK around the memory buffer β€” just as the zzip_disk_buffer function will do. πŸ¦‹

πŸ’€ another one: the zzip_disk_buffer function will not own the buffer β€” it will neither be written nor free()d. not your buffer, not your problem, don't touch it.

The zzip_disk_buffer function may return null (errno).

The zzip_disk_close function will release all data needed to access a (mmapped) zip archive, including any malloc()ed blocks, sharedmem mappings β€” and it dumps the handle struct as well. full cleanup, no crumbs left behind πŸ‘‘

And zzip_disk_close returns 0 on success (or whatever munmap says). periodt.


πŸ‘‘ AUTHOR πŸ‘‘

Guido Draheim <guidod@gmx.de>


Copyright (c)Guido Draheim, use under copyleft (LGPL,MPL)


okay that's the whole page bestie, and this was the zziplib 0.13.72 era of zzip_disk_mmap(3) β€” mwah, go mmap something and slay πŸ’–βœ¨πŸ¦‹

πŸ“¦ where this page comes from