Block-buffered I/O

[onitake]

I'm working on a project that interfaces with a file system on an SD card, and I'd prefer to support the stdio facilities if possible.

avr-libc's stdio library includes some extension points (custom get/put functions, user data), but the standard functions are written with unbuffered character devices in mind and don't seem to be very efficient for block-based buffered I/O.

What's the best way to integrate custom I/O functions, so that fwrite/fread is efficient, while still keeping compatibility with the (v)(f)printf function family? Or should I just give up on that idea and write a separate API for my disk I/O functionality?

[sprintersb]

What about implementing buffering in the put / get callbacks of FILE? Though functions like fflush don't really work: currently it's an inline function returning 0. But that could be changed. Then there is no means to flag that a flush is being called. You could provide that information in udata, but I don't see how / where it set that since fflush should't touch udata. Or new callbacks or flags could be added, which would require an ABI change: extending FILE.

One way would be to implement fflush as a proper function, then you could use GNU ld's --wrap <symbol> to wrap fflush or similar means.

[onitake]

Thanks for the hint to use --wrap.

I was planning to use buffering in single-character put/get anyway, but I thought it would improve performance to copy memory directly in fwrite/fread, without the calling get/put for every character. I suppose I could use --wrap for that as well, hmm...

Regarding fflush - what's the reason that the function is defined at all, if it's just a no-op? Is it being used somewhere?

[sprintersb]

fflush

I don't know why it is defined. On reason may be to reduce GCC testsuite fallout when a test case calls fflush.

And --wrap <symbol> will only work when you have a symbol to wrap. That's not the case when a function has been inlined.