Hello Nathan, Indeed, I should have mentioned that I have selected CONFIG_STDIO_DISABLE_BUFFERING. So, at least in my case, no buffering is taking place.
But in the case of buffered output, I think that I agree that fprintf() may return success for buffered (but not written) data. On Thu, Jul 20, 2023 at 10:16 PM Nathan Hartman <hartman.nat...@gmail.com> wrote: > On Thu, Jul 20, 2023 at 3:02 PM Fotis Panagiotopoulos <f.j.pa...@gmail.com > > > wrote: > > > Hello, > > > > I am using fprintf() to output some data to a file. This file is located > on > > an SD card. > > > > As I realised, fprintf() never returns an error. > > > > I tried to completely remove the SD card from the system, and fprintf > > happily succeeds, > > returning the number of bytes that it would have written, if the write > was > > successful. > > > > By checking the call trace, I see that the problem lies within > > vsprintf_internal(). > > It calls stream_putc() but no error checking is done there. > > > > Shouldn't this be considered a bug? > > > > I haven't studied the code, so I may be off here, but... > > If fprintf() return code indicates success to my application, my > expectation is that the data has been written. However it might be a little > more complicated than that: what if fprintf() successfully *buffered* the > data and the fs layer is waiting for an opportunity to write it? In this > scenario fprintf would return to the application before writing completes. > Then, it would be sensible for fprintf to indicate success (of the > buffering) even though data wasn't actually stored on flash yet. Maybe a > separate call to sync the fs is needed? > > Having said all that, stream_putc should probably do error checking and > propagate errors. > > Cheers > Nathan >
