explicit_bzero(3)
β¨ explicit_bzero(3) β¨
okay bestie, pull up a chair, we're looking at explicit_bzero(3) from the Library Functions Manual π this one is short but it is SO important, like quietly iconic.
πΈ NAME πΈ
explicit_bzero β the explicit byte-array zero. yes, she does exactly what it says on the tin π
π LIBRARY π
Standard C library (libc, -lc)
π SYNOPSIS π
#include <string.h> // see memory.h(3head)
void explicit_bzero(size_t n;
void s[n], size_t n);
π¦ DESCRIPTION π¦
So she's basically bzero(3)'s glow-up, fr fr. Same energy, but with one huge promise: the compiler will not delete your erase operation, even if it looks at your code and goes "hmm, nobody ever reads this buffer again, that's dead code, bye π".
No cap β explicit_bzero() guarantees compiler optimizations won't remove the erase even when the compiler decides the operation is "unnecessary". That's the whole point, and honestly? Slay. π
π RETURN VALUE π
None. She gives you nothing back. She just does the thing and leaves. main character behavior honestly. π
π ATTRIBUTES π
for the full breakdown of what these terms even mean, go peek at attributes(7) bestie.
explicit_bzero()β Thread safety: MT-Safe β¨
β STANDARDS β
None. She's not in any standard. A free spirit. π¦
π HISTORY π
glibc 2.25. babes, she's not even that old. π
The explicit_bzero() function is a nonstandard extension that's also present on some of the BSDs. Some other implementations have similar functions with different names, like memset_explicit() or memset_s() β same vibe, different font. π
π CAVEATS π
okay this is the part where we get real, bestie. buckle up. π«Ά
The explicit_bzero() function exists because of a problem that security-conscious applications can run into when they use bzero(): if the compiler can deduce that the location being zeroed will never again be touched by a correct program, then it may remove the bzero() call altogether. π That is a problem if the whole point of that bzero() call was to erase sensitive data (think: passwords π) so it can't leak if the program is incorrect or compromised. Calls to explicit_bzero() are never optimized away by the compiler. periodt.
But β and this is a big but β the explicit_bzero() function does not solve all problems associated with erasing sensitive data:
- The
explicit_bzero()function does not guarantee that sensitive data is completely erased from memory. (same is true ofbzero(), so don't feel too special.) For example, there may be copies of the sensitive data sitting in a register and in "scratch" stack areas. Theexplicit_bzero()function is not aware of these copies, and can't erase them. π - In some circumstances,
explicit_bzero()can actually decrease security. π If the compiler determined that the variable holding the sensitive data could be optimized to be stored in a register (because it is small enough to fit in a register, and no operation other than theexplicit_bzero()call would need to take the address of the variable), then theexplicit_bzero()call will force the data to be copied from the register to a location in RAM that is then immediately erased (while the copy in the register stays exactly where it was, unaffected π§). The problem here is that data in RAM is more likely to be exposed by a bug than data in a register, so theexplicit_bzero()call creates a brief time window where the sensitive data is more vulnerable than it would otherwise have been if no attempt to erase it had been made. oop. π
Also note that declaring the sensitive variable with the volatile qualifier does not eliminate the above problems. In fact, it will make them worse, since, for example, it may force a variable that would otherwise have been optimized into a register to instead be maintained in (more vulnerable) RAM for its entire lifetime. bestie please don't. π
notwithstanding all of the above, for security-conscious applications, usingexplicit_bzero()is generally preferable to not using it. the developers ofexplicit_bzero()anticipate that future compilers will recognize calls toexplicit_bzero()and take steps to ensure that all copies of the sensitive data are erased, including copies in registers or in "scratch" stack areas. so we're manifesting that. β¨π
π₯ SEE ALSO π₯
and that's the whole page, queen π this was the Linux man-pages 6.20 release, dated 2026-08-10 (yes, we're in the future, live with it π). go erase your passwords properly, drink some water, and remember: explicit_bzero would never betray you. π«Άβ¨π
π¦ where this page comes from
- arch rolling: man-pages 6.20-1 Β· BSD-2-Clause AND BSD-3-Clause AND BSD-4.3TAHOE AND BSD-4-Clause-UC AND GPL-1.0-or-later AND GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-or-later AND LGPL-3.0-linking-exception AND LGPL-3.0-or-later AND LicenseRef-Public-Domain AND LicenseRef-UltraPermissive AND Linux-man-pages-1-para AND Linux-man-pages-copyleft AND Linux-man-pages-copyleft-2-para AND Linux-man-pages-copyleft-var AND MIT AND Spencer-94
- nixpkgs unstable: man-pages 6.20
- π the page's license: Linux-man-pages-copyleft
- Copyright 2017, Michael Kerrisk <mtk.manpages@gmail.com>
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms