mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Thomas Weißschuh" <linux@weissschuh.net>
To: David Laight <david.laight.linux@gmail.com>
Cc: Daniel Palmer <daniel@thingy.jp>,
	w@1wt.eu,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] tools/nolibc: Add fread() to stdio.h
Date: Tue, 6 Jan 2026 12:02:18 +0100	[thread overview]
Message-ID: <9c043cdd-499c-48ae-8b1c-e49d541a8b2b@t-8ch.de> (raw)
In-Reply-To: <20260105110142.127eaba3@pumpkin>

On 2026-01-05 11:01:42+0000, David Laight wrote:
> On Mon, 5 Jan 2026 18:43:03 +0900
> Daniel Palmer <daniel@thingy.jp> wrote:
> > On Mon, 5 Jan 2026 at 18:27, David Laight <david.laight.linux@gmail.com> 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

  reply	other threads:[~2026-01-06 11:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-04  8:38 [PATCH 0/2] nolibc: Add fread() and fseek() Daniel Palmer
2026-01-04  8:38 ` [PATCH 1/2] tools/nolibc: Add fread() to stdio.h Daniel Palmer
2026-01-04  9:13   ` Thomas Weißschuh
2026-01-04 18:34   ` David Laight
2026-01-05  0:54     ` Daniel Palmer
2026-01-05  9:27       ` David Laight
2026-01-05  9:43         ` Daniel Palmer
2026-01-05 11:01           ` David Laight
2026-01-06 11:02             ` Thomas Weißschuh [this message]
2026-01-06 11:07               ` Willy Tarreau
2026-01-04  8:38 ` [PATCH 2/2] tools/nolibc: Add fseek() " Daniel Palmer
2026-01-04  9:11 ` [PATCH 0/2] nolibc: Add fread() and fseek() Thomas Weißschuh
2026-01-04 11:12   ` Daniel Palmer
2026-01-04 12:42     ` Willy Tarreau
2026-01-04 14:36     ` Thomas Weißschuh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9c043cdd-499c-48ae-8b1c-e49d541a8b2b@t-8ch.de \
    --to=linux@weissschuh.net \
    --cc=daniel@thingy.jp \
    --cc=david.laight.linux@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®