Re: [PATCH 1/2] tools/nolibc: Add fread() to stdio.h

[Thomas Weißschuh]

On 2026-01-05 11:01:42+0000, David Laight wrote:
> On Mon, 5 Jan 2026 18:43:03 +0900
> Daniel Palmer <daniel@xxxxxxxxx> wrote:
> > On Mon, 5 Jan 2026 at 18:27, David Laight <david.laight.linux@xxxxxxxxx> wrote:
> > > But you've deleted the partial bytes from the input.
> > > I'm sure that isn't right.
> > > Normally a FILE is buffered and the bytes are saved for the next read.
> > > Remember you can be reading from a pipe that is being written using
> > > 'block buffering' - so it is valid for only a partial 'item' be read.
> > > (I'm sure non-blocking IO is also valid...)  
> > 
> > I see now. If a partial read happens, the next call to fread() will
> > read from after the end of the partial read that happened and it'll be
> > broken.
> > Since in nolibc the FILE pointer that gets used isn't really a pointer
> > but the file descriptor I'm not sure where we'd stash the partial part
> > so we need to avoid doing the partial read entirely.
> 
> Except you can't really avoid the partial read.
> Doing multiple read() system calls doesn't help.
> The situation where it can happen probably doesn't happen for nolibc.

> Is there support for ferror() and/or feof() ?
> (a global 'u8 fstate[64]' indexed by fd number would probably suffice.)
> If so you could set the 'error' bit and then error any further fread()s.

No, neither of them is currently supported.
Given that the support for 'FILE *' is obviously somewhat limited in
general and the existing fwrite() shares the same issues, I am leaning
towards picking up these patches. We can then find a proper solution.

Users trying to use these APIs really correctly will quite fast find out
that ferror() and feof() are missing.

The only real solution for partial writes that I see with the current
architecture is to limit the 'size' argument to '1'.
Maybe even with a static assertion. But there still won't be any way to
properly signal the issue to the caller. Not that ferror() could
distinguish the types of error in any case...


Thomas