explain_mmap(3)
π NAME π
explain_mmap β ok bestie, it's the function that explains what tf went wrong with mmap(2) π
β¨ SYNOPSIS β¨
#include <libexplain/mmap.h>
const char *explain_mmap(void *data, size_t data_size, int prot, int
flags, int fildes, off_t offset);
const char *explain_errno_mmap(int errnum, void *data, size_t data_size,
int prot, int flags, int fildes, off_t offset);
void explain_message_mmap(char *message, int message_size, void *data,
size_t data_size, int prot, int flags, int fildes, off_t offset);
void explain_message_errno_mmap(char *message, int message_size, int
errnum, void *data, size_t data_size, int prot, int flags, int fildes,
off_t offset);
πΈ DESCRIPTION πΈ
Okay so here's the tea π« β these four functions are your little translators. You call mmap(2), it fails, and instead of you squinting at a cryptic number, one of these hands you back an actual explanation of what went wrong. They exist to explain errors returned by the mmap(2) system call. Slay.
π explain_mmap
const char *explain_mmap(void *data, size_t data_size, int prot, int
flags, int fildes, off_t offset);
So explain_mmap gets you an explanation of an error returned by the mmap(2) system call. The bare minimum the message will contain is the value of strerror(errno), but ngl it usually does way better than that and tells you the underlying cause in more detail. It's giving β¨detective energyβ¨.
It pulls the error value it's decoding from the errno global variable.
dataβ the original data, exactly as passed to themmap(2)system call. No edits, no vibes-based reinterpretation, just as it was π«Άdata_sizeβ the original data_size, exactly as passed to themmap(2)system call.protβ the original prot, exactly as passed to themmap(2)system call.flagsβ the original flags, exactly as passed to themmap(2)system call.fildesβ the original fildes, exactly as passed to themmap(2)system call.offsetβ the original offset, exactly as passed to themmap(2)system call.
Returns: the message explaining the error π. Heads up though β this message buffer is shared by all libexplain functions that don't take a buffer in their argument list. So the next call to any libexplain function sharing that buffer will overwrite it. Including calls from other threads. It's a communal water bottle, bestie, and everyone's drinking from it π
Note: this function is not thread safe, because it shares a return buffer across all threads β and like, so do many other functions in this library. Not me getting jumpscared by a race condition π
Example: you'd use this function kinda like so:
void *result = mmap(data, data_size, prot, flags, fildes,
offset);
if (!result)
{
fprintf(stderr, "%s\n", explain_mmap(data, data_size, prot,
flags, fildes, offset));
exit(EXIT_FAILURE);
}
And the best part?? That code example above is available pre-packaged as the explain_mmap_or_die(3) function. Obsessed. π
π¦ explain_errno_mmap
const char *explain_errno_mmap(int errnum, void *data, size_t data_size,
int prot, int flags, int fildes, off_t offset);
explain_errno_mmap gets you an explanation of an error returned by the mmap(2) system call. Least it'll contain is the value of strerror(errno), but usually it does way better and tells you the underlying cause in more detail π
errnumβ the error value to be decoded, usually grabbed from theerrnoglobal variable right before this function is called. And why does the timing matter, you ask? Because if you need to run any code between the system call you're explaining and this function, many libc functions will alter the value oferrnoπ so you gotta snag it early.dataβ the original data, exactly as passed to themmap(2)system call.data_sizeβ the original data_size, exactly as passed to themmap(2)system call.protβ the original prot, exactly as passed to themmap(2)system call.flagsβ the original flags, exactly as passed to themmap(2)system call.fildesβ the original fildes, exactly as passed to themmap(2)system call.offsetβ the original offset, exactly as passed to themmap(2)system call.
Returns: the message explaining the error π. Same deal as before: this message buffer is shared by all libexplain functions that don't supply a buffer in their argument list, and it gets overwritten by the next call to any libexplain function sharing it β other threads included. π«
Note: not thread safe, bestie, because it shares a return buffer across all threads, and so do many other functions in this library.
Example: intended to be used in a fashion similar to this:
void *result = mmap(data, data_size, prot, flags, fildes,
offset);
if (!result)
{
int err = errno;
fprintf(stderr, "%s\n", explain_errno_mmap(err, data,
data_size, prot, flags, fildes, offset));
exit(EXIT_FAILURE);
}
And yep β that code example above is also available pre-packaged as the explain_mmap_or_die(3) function. β¨
π§ explain_message_mmap
void explain_message_mmap(char *message, int message_size, void *data,
size_t data_size, int prot, int flags, int fildes, off_t offset);
explain_message_mmap gets you an explanation of an error returned by the mmap(2) system call. Minimum content: the value of strerror(errno). Usually though? Much better, with the underlying cause spelled out in more detail π
It uses the errno global variable to get the error value it's decoding.
messageβ where you want the returned message stored π₯. And the slay here: if you supply a suitable message return buffer, this function is thread safe. Periodt.message_sizeβ the size in bytes of the location where you're storing the returned message.dataβ the original data, exactly as passed to themmap(2)system call.data_sizeβ the original data_size, exactly as passed to themmap(2)system call.protβ the original prot, exactly as passed to themmap(2)system call.flagsβ the original flags, exactly as passed to themmap(2)system call.fildesβ the original fildes, exactly as passed to themmap(2)system call.offsetβ the original offset, exactly as passed to themmap(2)system call.
Example: use it kinda like this:
void *result = mmap(data, data_size, prot, flags, fildes,
offset);
if (!result)
{
char message[3000];
explain_message_mmap(message, sizeof(message), data,
data_size, prot, flags, fildes, offset);
fprintf(stderr, "%s\n", message);
exit(EXIT_FAILURE);
}
You already know what I'm about to say β that code example above is available pre-packaged as the explain_mmap_or_die(3) function. π
π explain_message_errno_mmap
void explain_message_errno_mmap(char *message, int message_size, int
errnum, void *data, size_t data_size, int prot, int flags, int fildes,
off_t offset);
explain_message_errno_mmap gets you an explanation of an error returned by the mmap(2) system call. Least it'll contain is the value of strerror(errno), but usually it goes way harder and shows the underlying cause in more detail. Iconic behaviour, honestly.
messageβ the location to store the returned message π¬. If a suitable message return buffer is supplied, this function is thread safe β main character energy fr fr.message_sizeβ the size in bytes of the location where the returned message goes.errnumβ the error value to be decoded, usually taken from theerrnoglobal variable just before this function is called. This matters if you need to call any code between the system call being explained and this function, because many libc functions will alter the value oferrnoπdataβ the original data, exactly as passed to themmap(2)system call.data_sizeβ the original data_size, exactly as passed to themmap(2)system call.protβ the original prot, exactly as passed to themmap(2)system call.flagsβ the original flags, exactly as passed to themmap(2)system call.fildesβ the original fildes, exactly as passed to themmap(2)system call.offsetβ the original offset, exactly as passed to themmap(2)system call.
Example: the vibe is something like this:
void *result = mmap(data, data_size, prot, flags, fildes,
offset);
if (!result)
{
int err = errno;
char message[3000];
explain_message_errno_mmap(message, sizeof(message), err,
data, data_size, prot, flags, fildes, offset);
fprintf(stderr, "%s\n", message);
exit(EXIT_FAILURE);
}
And of course, that code example above is available pre-packaged as the explain_mmap_or_die(3) function. π
π SEE ALSO π
mmap(2)β map file or device into memoryexplain_mmap_or_die(3)β map file or device into memory and report errors
π COPYRIGHT π
That's a wrap, bestie π«Ά β this whole thing is libexplain version 1.4, copyright (C) 2010 Peter Miller. Go forth and explain your mmap(2) errors with confidence, and remember: the buffer is shared, the knowledge is not. π
β¨
explain_mmap(3) β out π
π¦ where this page comes from
- debian bookworm: libexplain-dev 1.4.D001-12+b1 Β· LGPL-3.0-or-later
- debian trixie: libexplain-dev 1.4.D001-16 Β· LGPL-3.0-or-later
- ubuntu jammy: libexplain-dev 1.4.D001-12 Β· LGPL-3.0-or-later
- ubuntu noble: libexplain-dev 1.4.D001-13 Β· LGPL-3.0-or-later
- ubuntu resolute: libexplain-dev 1.4.D001-16 Β· LGPL-3.0-or-later
- Copyright (C) 2010, 2011 Peter Miller
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms