ERR_LOAD_CRYPTO_STRINGS(3)

okay bestie, welcome to the ERR_LOAD_CRYPTO_STRINGS(3) page from the Library Functions Manual — this one is short but it has deprecated energy all over it, so let's get into it 💅

✨ NAME ✨

• ERR_load_crypto_strings, ERR_free_strings, SSL_load_error_strings — load and free OpenSSL error strings.

🦋 SYNOPSIS 🦋

bestie, the synopsis is giving “two libraries, three functions” and it goes exactly like this:

library “libcrypto” #include <openssl/err.h>

void
ERR_load_crypto_strings(void);

void
ERR_free_strings(void);

library “libssl” libcrypto

#include <openssl/ssl.h>

void
SSL_load_error_strings(void);

💅 DESCRIPTION 💅

Okay so these functions are deprecated — like, do not use them. It is never useful for any application program to call any of them explicitly. The library automatically calls them internally whenever needed. No cap.

• ERR_load_crypto_strings() registers the error strings for all crypto(3) functions.
• SSL_load_error_strings() does the same, but also registers the ssl(3) error strings.
• If the error strings were already loaded before, no action occurs — literally nothing happens.
• ERR_free_strings() frees all previously loaded error strings.

🔥 SEE ALSO 🔥

• ERR(3)
• ERR_error_string(3)
• OPENSSL_config(3)

🌸 HISTORY 🌸

• ERR_load_crypto_strings() and SSL_load_error_strings() first appeared in SSLeay 0.4.4.
• ERR_free_strings() first appeared in SSLeay 0.5.1.
• These functions have been available since OpenBSD 2.4.

💀 BUGS 💀

bestie, this is the messy part. Even though the error strings are already compiled into the object code of the library as static strings, these functions store them again using dynamically allocated memory on the heap. That may fail if insufficient memory is available, but these functions do not report such errors. Instead, they fail silently, possibly having registered none or only a part of the strings requested.

okay that's the whole page! source/version: Debian; date: June 8, 2025 — mwah 💖