4 ms·
I was thinking it would be nice if there were a generic VFS library for C that offered stdio-like APIs (fread, fprintf, etc.) in order to do tricks like this be
by rgovostes 4y ago
I was thinking it would be nice if there were a generic VFS library for C that offered stdio-like APIs (fread, fprintf, etc.) in order to do tricks like this beyond SQLite, without having to make major changes porting existing codebases over to different APIs.
It occurs to me that because a FILE * is an opaque pointer, it ought to be possible for a libc to provide this functionality: the FILE struct could contain function pointers to the the underlying implementations for writing, flushing, etc.
This ought to be backwards compatible with existing FILE * returning APIs (fopen, fdopen, popen), while allowing new backing stores without having to rewrite (or even recompile) existing code.
- teraflop 4y agoYou're in luck: https://www.gnu.org/software/libc/manual/html_node/Streams-and-Cookies.html https://www.gnu.org/software/libc/manual/html_node/Streams-a...
- rgovostes 4y agoThanks! Looks like it is a glibc (and musl) feature, though this led me to discover funopen() in BSD and macOS: https://man.openbsd.org/funopen.3 https://man.openbsd.org/funopen.3
- vlovich123 4y agoLocal file semantics like FILE* don't map well to how large scale object storage systems operate. For example, FILE* supports seeking (specifically for writes) and mutating files after construction whereas object storage systems generate immutable copies of files once made visible after uploading. There's also no fsync. FWIW S3 kind of is that "de facto" interface. There were attempts at standardizing it via OpenStack's SWIFT project but to my eye S3 remains the industry de facto for better or worse.