BIO_S_MEM(3ossl)

💾 BIO_S_MEM 💾

okay so bestie, welcome to the memory BIO page — this is the 3ossl one, aka the OpenSSL girlies' manual. it covers BIO_s_secmem, BIO_s_dgram_mem, BIO_s_mem, BIO_set_mem_eof_return, BIO_get_mem_data, BIO_set_mem_buf, BIO_get_mem_ptr and BIO_new_mem_buf, and no, that's not a typo, there are genuinely that many. buckle up 💅

---

✨ SYNOPSIS ✨

#include <openssl/bio.h>

const BIO_METHOD *BIO_s_mem(void);
const BIO_METHOD *BIO_s_dgram_mem(void);
const BIO_METHOD *BIO_s_secmem(void);

BIO_set_mem_eof_return(BIO *b, int v);
long BIO_get_mem_data(BIO *b, char **pp);
BIO_set_mem_buf(BIO *b, BUF_MEM *bm, int c);
BIO_get_mem_ptr(BIO *b, BUF_MEM **pp);

BIO *BIO_new_mem_buf(const void *buf, int len);

---

🫶 DESCRIPTION 🫶

BIO_s_mem() hands you back the memory BIO method function, like, the whole personality of a memory BIO in one pointer. iconic.

A memory BIO is a source/sink BIO that uses memory for its I/O — no sockets, no files, just vibes and RAM. anything you write to it gets stored in a BUF_MEM structure, which grows as needed to fit whatever you're storing. it literally just expands to accommodate you, no cap. 🌱

BIO_s_secmem() is exactly like BIO_s_mem() except the secure heap is used for buffer storage. fancy secure-heap energy. 🔐

BIO_s_dgram_mem() is a memory BIO that respects datagram semantics, which is a whole different beastie. one single call to BIO_write(3) writes one single datagram into the memory BIO. then a subsequent call to BIO_read(3) reads the data in that datagram. and here's the slay part: the BIO_read(3) call will never return more data than was written in the original BIO_write(3) call — even if there were later BIO_write(3) calls that wrote more datagrams. each successive BIO_read(3) call reads the next datagram, one at a time, in order. 🎀

and if a BIO_read(3) call gives you a read buffer that's smaller than the datagram size? then the read buffer gets completely filled and the leftover data from that datagram is discarded. gone. bye. 😭

you literally cannot write a zero-length datagram — calling BIO_write(3) in that case returns 0 and no datagrams get written. and calling BIO_read(3) when there are no datagrams in the BIO to read returns a negative result and the "retry" flags get set (meaning BIO_should_retry(3) returns true). also, a datagram mem BIO will never return true from BIO_eof(3) — it's just not that kind of BIO.

any data written to a memory BIO can be recalled by reading from it. and unless the memory BIO is read only, any data read from it is deleted from the BIO. so it's giving "read it and it's gone." 💀

memory BIOs except BIO_s_dgram_mem() support BIO_gets() and BIO_puts(). dgram girlies stay excluded, iykyk.

BIO_s_dgram_mem() supports BIO_sendmmsg(3) and BIO_recvmmsg(3) calls, plus calls related to BIO_ADDR and MTU handling, similarly to the BIO_s_dgram_pair(3). so yes, it's in the group chat. 🦋

if the BIO_CLOSE flag is set when a memory BIO is freed, then the underlying BUF_MEM structure is also freed. package deal.

calling BIO_reset() on a read write memory BIO clears any data in it — if the flag BIO_FLAGS_NONCLEAR_RST is not set. if it is set, it just restores the read pointer to the state it was in right after the last write was performed, and the data can be read again. on a read only BIO it similarly restores the BIO to its original state, and the read only data can be read again. 🔁

BIO_eof() is true if no data is in the BIO. empty = eof, simple as.

BIO_ctrl_pending() returns the number of bytes currently stored. the little counter keeping track. 📊

BIO_set_mem_eof_return() sets the behaviour of memory BIO b when it's empty. if v is zero, then an empty memory BIO will return EOF (that is, it will return zero and BIO_should_retry(b) will be false). if v is non zero, then it will return v when it's empty and it will set the read retry flag (that is, BIO_read_retry(b) is true). to avoid ambiguity with a normal positive return value, v should be set to a negative value — typically -1. and ngl, calling this macro will fail for datagram mem BIOs. 🚫

BIO_get_mem_data() sets *pp to a pointer to the start of the memory BIOs data and returns the total amount of data available. it's implemented as a macro, so yes it's that kind of function. note that the pointer returned by this call is informative — no transfer of ownership of this memory is implied, bestie. see the notes on BIO_set_close(). 👀

BIO_set_mem_buf() sets the internal BUF_MEM structure to bm and sets the close flag to c, meaning c should be either BIO_CLOSE or BIO_NOCLOSE. it is a macro. 🎯

BIO_get_mem_ptr() places the underlying BUF_MEM structure in *pp. also a macro. ✨

BIO_new_mem_buf() creates a memory BIO using len bytes of data at buf. if len is -1 then buf is assumed to be nul terminated and its length is determined by strlen. the BIO is set to a read only state and as a result cannot be written to. this is useful when some data needs to be made available from a static area of memory in the form of a BIO. and the supplied data is read directly from the supplied buffer — it is not copied first — so the supplied area of memory must be unchanged until the BIO is freed. no cap, that's a real constraint. 🙈

all of the five functions described above return an error with BIO_s_dgram_mem(). every single one. group project grade: error. 😭

---

📝 NOTES 📝

writes to memory BIOs will always succeed if memory is available — meaning their size can grow indefinitely. which is slay until it isn't. 🫠 the one exception is BIO_s_dgram_mem() when BIO_set_write_buf_size(3) is called on it. in that case the write buffer size becomes fixed, and any writes that would overflow the buffer will return an error.

every write after a partial read (meaning not all data in the memory buffer was read) on a read write memory BIO will have to move the unread data with an internal copy operation. so if a BIO contains a lot of data and it's read in small chunks intertwined with writes, the operation can be very slow. adding a buffering BIO to the chain can speed up the process — the internal copy is doing the most and needs a break. 💅

calling BIO_set_mem_buf() on a secmem or dgram BIO will give undefined results, including perhaps a program crash. do not.

switching a memory BIO from read write to read only is not supported and can give undefined results including a program crash. not supported, not cute, not doing it.

there are two notable exceptions to that rule, though. first one: assign a static memory buffer immediately after BIO creation and set the BIO as read only. 🎀

the other supported sequence is to start with a read write BIO, then temporarily switch it to read only and call BIO_reset() on the read only BIO immediately before switching it back to read write. before the BIO is freed it must be switched back to read write mode. order matters, bestie, do not freestyle this. 🌈

calling BIO_get_mem_ptr() on a read only BIO will return a BUF_MEM that contains only the remaining data to be read. if the close status of the BIO is set to BIO_NOCLOSE, then before freeing the BUF_MEM the data pointer in it must be set to NULL, because the data pointer does not point to an allocated memory. ⚠️

calling BIO_reset() on a read write memory BIO with the BIO_FLAGS_NONCLEAR_RST flag set can have an unexpected outcome when the reads and writes to the BIO are intertwined. as documented above, the BIO will be reset to the state after the last completed write operation — and the effects of reads preceding that write operation cannot be undone. 😬

calling BIO_get_mem_ptr() prior to a BIO_reset() call with BIO_FLAGS_NONCLEAR_RST set has the same effect as a write operation. sneaky.

calling BIO_set_close() with BIO_NOCLOSE orphans the BUF_MEM internal to the BIO — _not_ its actual data buffer. see the examples section for the proper method for claiming ownership of the data pointer for a deferred free operation. the examples are giving "here's the receipts." 🧾

---

💜 RETURN VALUES 💜

• BIO_s_mem(), BIO_s_dgram_mem() and BIO_s_secmem() return a valid memory BIO_METHOD structure. ✨
• BIO_set_mem_eof_return(), BIO_set_mem_buf() and BIO_get_mem_ptr() return 1 on success, or a value which is less than or equal to 0 if an error occurred.
• BIO_get_mem_data() returns the total number of bytes available on success, 0 if b is NULL, or a negative value in case of other errors.
• BIO_new_mem_buf() returns a valid BIO structure on success or NULL on error. 😭

---

🌸 EXAMPLES 🌸

create a memory BIO and write some data to it:

BIO *mem = BIO_new(BIO_s_mem());

BIO_puts(mem, "Hello World\n");

create a read only memory BIO:

char data[] = "Hello World";
BIO *mem = BIO_new_mem_buf(data, -1);

extract the BUF_MEM structure from a memory BIO and then free up the BIO:

BUF_MEM *bptr;

BIO_get_mem_ptr(mem, &bptr);
BIO_set_close(mem, BIO_NOCLOSE); /* So BIO_free() leaves BUF_MEM alone */
BIO_free(mem);

extract the BUF_MEM ptr, claim ownership of the internal data and free the BIO and BUF_MEM structure:

BUF_MEM *bptr;
char *data;

BIO_get_mem_data(bio, &data);
BIO_get_mem_ptr(bio, &bptr);
BIO_set_close(mem, BIO_NOCLOSE); /* So BIO_free orphans BUF_MEM */
BIO_free(bio);
bptr->data = NULL; /* Tell BUF_MEM to orphan data */
BUF_MEM_free(bptr);
...
free(data);

---

🦋 HISTORY 🦋

BIO_s_dgram_mem() was added in OpenSSL 3.2. she's the new girl and she's already main character energy.

---

👑 COPYRIGHT 👑

Copyright 2000-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

---

and that's the whole page, bestie — go read some memory, drink some water, and remember: this was 3.5.6, dated 2026-04-07, from the OpenSSL fam, filed under BIO_S_MEM(3ossl). periodt. 💖✨🎀