虚拟化C的FILE*接口有多可行？

Question

它经常注意到,如果有一种方法可以创建一个"虚拟FILE"并为缓冲区已满,请求输入,关闭,刷新等事件附加必要的回调,我本可以优雅地解决C中的实际问题.然后应该可以使用大部分stdio.h功能,例如fprintf不变.有没有一个框架可以做到这一点？如果没有,至少在某些平台上,是否可以通过适度的努力？

可能的应用是:

• 写入或读取动态或静态内存区域.
• 并行写入多个文件.
• 从生成数据的线程或协同例程中读取.
• 将过滤器应用于另一个(虚拟或真实)FILE.
• 支持间接的文件格式(如#include).
• AC预处理器(？).

我对特定案例的解决方案不太感兴趣,而不是在框架中让你自己动手FILE.我也不是在寻找虚拟文件系统,而是寻找FILE*可以传递给CRT 的虚拟文件系统.

令我失望的是,我从未见过任何类似的东西; 据我所知,C11 FILE完全取决于语言实现者,如果你希望保持语言(+库)规范的小而且将它与Java I/O流进行比较,这可能是合理的.

我确信虚拟FILEs必须可以与C运行时的任何(完全)开源实现,但我想可能有大量的细节使它比看起来更棘手,如果它已经完成它重复努力将是一种耻辱.不必修改CRT代码也是非常可取的.如果没有开源,我们可能会对所提供的功能进行逆向工程,但我担心结果太容易受到不支持功能的影响,除非有对一组接口的承诺.我想也是任何可以编写设备驱动程序的系统都可以创建一个虚拟设备,但我怀疑它是不必要的低级别并且需要一个人编写特权代码.

我不得不承认,虽然我的代码可以从虚拟代码中受益FILE,但我目前没有要求它; 尽管如此,这是我经常想知道的事情,我想其他人可能会感兴趣.

这有点类似于a-reader-interface-consumes-files-and-char-in-c,但提问者不希望返回虚拟FILE; 然而,答案是,使用fmemopen了.

Answer 1

没有用于创建虚拟FILE*的标准C接口,但GNU和BSD标准库都包含一个.在linux(glibc)上,你可以使用fopencookie ; 在大多数*BSD系统上,funopen(包括Mac OS X).(见注1)

两个接口类似,但在某些细节上略有不同.但是,将为一个接口编写的代码调整到另一个接口通常非常简单.

这些不是完整的虚拟化.他们将FILE*四个回调和一个void*上下文("cookie" fopencookie)联系在一起.回调是read,write,seek和close; 没有回调flush或tell操作.不过,这对于许多简单的FILE*适配器来说已经足够

举一个简单的例子,请看两个同时写入两个流的答案.

笔记:

1. funopen 源自"功能开放",而不是"文件未打开".