如何扩展libc的fmemopen流，实现fclose时自动释放缓冲区？

一、利用libc Cookie机制实现自动释放（替代全局跟踪） #

glibc和musl都支持自定义流的cookie机制，但直接“继承”fmemopen返回的FILE*并修改回调不可行——FILE是不透明结构体，fmemopen内部已绑定自身的cookie与回调。正确思路是包装fmemopen，创建自定义cookie流复用其读写逻辑：

实现步骤 #

1. 定义自定义cookie结构体，存储缓冲区指针与fmemopen生成的原始流：

typedef struct {
    void *buf;
    FILE *mem_fp;
} AutoFreeCookie;

2. 实现包装回调，将读写、定位操作转发给原始fmemopen流，close回调额外添加缓冲区释放逻辑：

static ssize_t auto_free_read(void *cookie, char *buf, size_t size) {
    AutoFreeCookie *c = cookie;
    return fread(buf, 1, size, c->mem_fp);
}

static ssize_t auto_free_write(void *cookie, const char *buf, size_t size) {
    AutoFreeCookie *c = cookie;
    return fwrite(buf, 1, size, c->mem_fp);
}

static fpos_t auto_free_seek(void *cookie, fpos_t offset, int whence) {
    AutoFreeCookie *c = cookie;
    if (fseek(c->mem_fp, offset, whence) == 0) {
        return ftell(c->mem_fp);
    }
    return -1;
}

static int auto_free_close(void *cookie) {
    AutoFreeCookie *c = cookie;
    int ret = fclose(c->mem_fp);
    free(c->buf);
    free(c);
    return ret;
}

3. 编写包装函数fmemopen_auto_free，适配glibc与musl的cookie流创建接口：

FILE *fmemopen_auto_free(void *buf, size_t size, const char *mode) {
    AutoFreeCookie *c = malloc(sizeof(AutoFreeCookie));
    if (!c) return NULL;
    c->buf = buf;
    c->mem_fp = fmemopen(buf, size, mode);
    if (!c->mem_fp) {
        free(c);
        return NULL;
    }

    FILE *fp = NULL;
#ifdef __GLIBC__
    fp = funopen(c, auto_free_read, auto_free_write, auto_free_seek, auto_free_close);
#elif defined(__MUSL__)
    fp = fopencookie(c, mode, (cookie_io_functions_t){
        .read = auto_free_read,
        .write = auto_free_write,
        .seek = auto_free_seek,
        .close = auto_free_close
    });
#endif

    if (!fp) {
        fclose(c->mem_fp);
        free(c->buf);
        free(c);
    }
    return fp;
}

该方案既复用了fmemopen的成熟读写逻辑，又通过自定义close回调实现缓冲区自动释放，天然兼容glibc与musl。

二、从fmemopen的FILE*中取回缓冲区指针（跨平台限制） #

不存在完全可移植的方法，因为FILE是不透明结构体，fmemopen的内部实现细节在glibc与musl中完全不同：

• glibc中，fmemopen的FILE关联的cookie是私有结构体struct memstream，包含缓冲区指针，但无公开API可获取，强行访问会破坏ABI兼容性。
• musl中，fmemopen的FILE直接将缓冲区存储在_bf._base字段，同样属于未公开的内部实现，版本升级可能失效。

若必须取回缓冲区，只能针对不同libc做兼容hack（不推荐用于生产环境）：

void *fmemopen_get_buf(FILE *fp) {
#ifdef __GLIBC__
    struct memstream {
        void *buf;
        size_t size, alloc;
        int mode;
    };
    return ((struct memstream*)fp->__cookie)->buf;
#elif defined(__MUSL__)
    return fp->_bf._base;
#else
    return NULL;
#endif
}

更可靠的方式是创建流时自行维护缓冲区指针的映射（即你之前使用的数组跟踪方案）。

三、方案对比 #

• 全局跟踪方案：简单直接，但需手动管理映射，易因遗漏自定义close函数导致内存泄漏。
• Cookie包装方案：符合libc流设计范式，自动绑定释放逻辑，无需额外跟踪，仅需处理不同libc的接口差异。

内容的提问来源于stack exchange，提问作者Vadim Kantorov