MANDOC_MALLOC(3)
π MANDOC_MALLOC β Library Functions Manual π
okay bestie, sit down, hydrate, and let me tell you about the mandoc memory wrappers π these live in the Library Functions Manual section 3, and they are genuinely the most drama-free way to allocate memory that exists. no cap.
β¨ NAME β¨
mandoc_malloc, mandoc_realloc, mandoc_reallocarray, mandoc_calloc, mandoc_recallocarray, mandoc_strdup, mandoc_strndup, mandoc_asprintf β memory allocation function wrappers used in the mandoc library π«Ά
πΈ SYNOPSIS πΈ
#include <sys/types.h>
#include <mandoc_aux.h>
void *
mandoc_malloc(size_t size);
void *
mandoc_realloc(void *ptr, size_t size);
void *
mandoc_reallocarray(void *ptr, size_t nmemb, size_t size);
void *
mandoc_calloc(size_t nmemb, size_t size);
void *
mandoc_recallocarray(void *ptr, size_t oldnmemb, size_t nmemb,
size_t size);
char *
mandoc_strdup(const char *s);
char *
mandoc_strndup(const char *s, size_t maxlen);
int
mandoc_asprintf(char **ret, const char *format, ...);
π DESCRIPTION π
so here's the tea π these functions call the libc functions of the same names, and they pass through the return values when everything's successful. but when it fails? they do not return. they call err(3) instead. like, they simply refuse to hand you a broken pointer. iconic behavior honestly π
they can be used both internally by any code in the mandoc libraries and externally by programs using that library β for example mandoc(1), man(1), apropos(1), makewhatis(8), and man.cgi(8). so yes, they're for everyone, we share π
mandoc_malloc()β allocates one new object, and leaves the memory uninitialized. it does not clean up after itself, that's on you bestie.mandoc_realloc(),mandoc_reallocarray(), andmandoc_recallocarray()β change the size of an existing object or array, and they might move it somewhere else entirely (main character relocation energy). when you're shrinking the size, existing data gets truncated βοΈ; when you're growing, onlymandoc_recallocarray()initializes the new elements to zero. the others? they leave that new space just... vibing. uninitialized.mandoc_calloc()β allocates a new array and initializes it to zero. so clean, so fresh β¨
now the arguments, one by one:
sizeβ the size of each object.nmembβ the new number of objects in the array.oldnmembβ the number of objects in the array before the call.ptrβ a pointer to the existing object or array to be resized. and if it'sNULL? a whole new object or array gets allocated π¦
the string girlies:
mandoc_strdup()andmandoc_strndup()copy a string into newly allocated memory. formandoc_strdup(), the string pointed to bysneeds to beNUL-terminated. formandoc_strndup(), at mostmaxlenbytes are copied.mandoc_asprintf()writes output formatted according toformatinto newly allocated memory and returns a pointer to the result inret.
for all three string functions, the result is always NUL-terminated. always. periodt.
and when the objects and strings are no longer needed, the pointers returned by these functions can be passed to free(3) π
β RETURN VALUES β
mandoc_asprintf()β always returns the number of characters written, excluding the finalNULbyte. it never returns-1. never ever. not once.- the other functions β always return a valid pointer. they never return
NULL. that's just not a thing they do π
π FILES π
these functions are implemented in mandoc_aux.c.
π SEE ALSO π
asprintf(3), err(3), malloc(3), strdup(3)
π STANDARDS π
malloc(),realloc(), andcalloc()are required by ANSI X3.159-1989 (βANSI C89β).strdup()andstrndup()are required by IEEE Std 1003.1-2008 (βPOSIX.1β).asprintf()is a widespread extension that first appeared in the GNU C library.
and now the portable ones, pay attention bestie:
reallocarray()is an extension that first appeared in OpenBSD 5.6, andrecallocarray()in OpenBSD 6.1. if these two are not provided by the operating system, the mandoc build system uses bundled portable implementations. so you're covered either way π«Ά
π¦ HISTORY π¦
the timeline, in order, no skips:
mandoc_malloc(),mandoc_realloc(),mandoc_calloc(), andmandoc_strdup()β available since mandoc 1.9.12mandoc_strndup()β since 1.11.5mandoc_asprintf()β since 1.12.4mandoc_reallocarray()β since 1.13.0mandoc_recallocarray()β since 1.14.2
they've been growing up so fast π
π AUTHORS π
- Kristaps Dzonsons
<kristaps@bsd.lv> - Ingo Schwarze
<schwarze@openbsd.org>
and that's the whole page, bestie π§ this one came from Debian, dated September 17, 2021, living in section MANDOC_MALLOC(3). go forth and never check a malloc return value again β that's literally the whole point π β¨
π¦ where this page comes from
- alpine 3.22: mandoc-doc 1.14.6-r13 Β· ISC
- alpine 3.23: mandoc-doc 1.14.6-r14 Β· ISC
- alpine 3.24: mandoc-doc 1.14.6-r15 Β· ISC
- debian trixie: libmandoc-dev 1.14.6-4 Β· ISC
- epel 10: libmandoc-devel 1.14.6-11.el10_1 Β· ISC AND BSD-2-Clause AND BSD-3-Clause
- epel 9: libmandoc-devel 1.14.6-2.el9 Β· ISC
- fedora 43: libmandoc-devel 1.14.6-12.fc43 Β· ISC AND BSD-2-Clause AND BSD-3-Clause
- fedora 43: libmandoc-devel 1.14.6-12.fc43 Β· ISC AND BSD-2-Clause AND BSD-3-Clause
- fedora 44: libmandoc-devel 1.14.6-13.fc44 Β· ISC AND BSD-2-Clause AND BSD-3-Clause
- fedora 44: libmandoc-devel 1.14.6-13.fc44 Β· ISC AND BSD-2-Clause AND BSD-3-Clause
- ubuntu questing: libmandoc-dev 1.14.6-4
- ubuntu resolute: libmandoc-dev 1.14.6-4build1 Β· ISC
- ubuntu stonking: libmandoc-dev 1.14.6-4build1 Β· ISC
- Copyright (c) 2014 Ingo Schwarze <schwarze@openbsd.org>
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms