BIO_DUP_CHAIN(3)

📦 version 4.4.0, in alpine 3.24, arch rolling

🌸 NAME 🌸

BIO_dup_chain, BIO_dup_state — copy a BIO chain, bestie 💅

okay so welcome to BIO_DUP_CHAIN(3) from the Library Functions Manual — she's giving very specific crypto-library energy and we're gonna get into it 🫶

✨ SYNOPSIS ✨

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

BIO *
BIO_dup_chain(BIO *b);

long
BIO_dup_state(BIO *b, BIO *new_bio);

🦋 DESCRIPTION 🦋

BIO_dup_chain() copies the chain starting at b by iteratively copying b and all the BIOs following it, then joining the copies in the same order as in the original chain. The copying operation is neither a deep copy nor a shallow copy — she's her own little hybrid vibe, no cap 😭

Some parts of the state of each BIO are copied, in particular with respect to the values returned by BIO_get_init(3), BIO_test_flags(3), and BIO_get_shutdown(3). Other parts of the state of the BIOs are not copied but instead initialized to 0, in particular with respect to the values returned by BIO_number_read(3), BIO_number_written(3), and BIO_get_retry_reason(3). The custom data pointer that can be used by custom BIO types and that can be retrieved with BIO_get_data(3) is set to NULL in the copied BIO objects rather than copied. The reference count of each BIO in the copied chain is set to 1. periodt 💅

For each BIO in the chain, copying the data that was set with BIO_set_ex_data(3) is attempted, which may involve calling application-defined callback functions. yes bestie, callbacks may absolutely be involved 🙈

The following pointers are copied rather than creating deep copies of the objects pointed to:

  • The type pointer used for creating each BIO with BIO_new(3), implying that functions like BIO_method_name(3) return pointers to the same strings for the BIOs in the copied chain, and that these strings are not copied. same string energy, no duplicate strings 💖
  • All function pointers, in particular those installed with BIO_set_callback_ex(3) and BIO_get_callback_ex(3).
  • The pointer installed with BIO_set_callback_arg(3), which implies that for BIOs using BIO_debug_callback(3), those in the copied chain use the same BIOs for debugging output as the corresponding ones in the original chain, and none of the debugging output BIOs are copied. iconic shared-debug-output behavior, honestly 🔥

BIO_dup_state() is a macro that calls BIO_ctrl(3) with a cmd argument of BIO_CTRL_DUP. It is automatically called for each BIO during BIO_dup_chain() after the copied BIO is initialized and data copied into it, but before the data set with BIO_set_ex_data(3) is copied into the new BIO and before it is linked into the new chain. the timing is very specific and we respect the timing 🎀

This control operation may modify the operation of BIO_dup_chain() for particular types of BIOs contained in the chain, for example initializing or copying additional data. For BIO types provided by the library, such additional effects are documented in the respective manual pages, in particular in BIO_f_buffer(3), BIO_f_cipher(3), BIO_f_md(3), BIO_f_ssl(3), BIO_s_bio(3), and BIO_s_connect(3). so yes, some BIO types have extra lore and you should check their pages, iykyk 🌈

⚠️ lowkey important: this is not a deep copy and not a shallow copy. do not assume either one, bestie. the manpage said what it said 💀

👑 RETURN VALUES 👑

BIO_dup_chain() returns a pointer to the newly allocated copy of the BIO b on success or NULL on failure. she either serves you a fresh copy or gives you nothing, dramatic but fair 😭

BIO_dup_state() returns 1 on success or a value less than or equal to zero on failure. simple math, no cap ✨

🧚 SEE ALSO 🧚

go read these if you want the full group-chat context, bestie 🫶

⭐ HISTORY ⭐

BIO_dup_chain() and BIO_dup_state() first appeared in SSLeay 0.8.0 and have been available since OpenBSD 2.4. vintage behavior, honestly 💜

mwah 💋 this page was brought to you by Debian, dated June 8, 2025, and it's serving pure BIO_DUP_CHAIN(3) main-character energy — xoxo, go copy a chain responsibly 🎀💖

📦 where this page comes from