From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.formilux.org (mta1.formilux.org [51.159.59.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4867B175A5 for ; Tue, 6 Jan 2026 11:07:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=51.159.59.229 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767697639; cv=none; b=FcRaxWLwYiOJNWVh7t6YnEJqW/Ns36JA4aEYEyNe3XuXQLsgpsekIdzbMTKfI8mHAvCZ6tw18rVfozssdtnUGUnziP97mz6GrhaNjIfxb5PbSlSTPqUQCrGMwmRR8Q0Iuq3NRJr8X1Nl2WZlNWCOcmjD8aZJvoXZxS2xhfNtAyM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767697639; c=relaxed/simple; bh=rVBiLv7FjNoTuCvH2WKeJMqRP8dZA1sSRRwTvTkMdWU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LqaPXr5ugWpzhGrzD7A3FHOwXv9NBqys6DLa47f3cAeB28dSXMYme/YAvpN260m3lMzuPs/F9p74PT3rMgsaL+nA+cGKUi3YLxdF4YICkgdFG9Wv7SK34821zNBCLI7JGzihyENdmyHyv6vvRuB4T1t8IBN9oOUgzygfkqFtBSk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu; spf=pass smtp.mailfrom=1wt.eu; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b=uoJ7Lgrw; arc=none smtp.client-ip=51.159.59.229 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=1wt.eu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b="uoJ7Lgrw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1767697635; bh=LIo9qZiRUKtmJNFNV/2ZQoY0g1ugp//Q5Olj/UEcCeY=; h=From:Message-ID:From; b=uoJ7Lgrw9QUwR5nJMSr/0WaxDkHsxY30tO4iR0PUP9DUO/hJMuBNNHtYEzy8zYtbU +7tKeM64GXdxX/Iv33RuCr6LMpyzCqTvihb5lORGCGiWFseQEhdMGMG0W0dUxnM2kK AuB5wQLRtoem/CMFkzbUCv1tbgfZE4hGWbM5hQrU= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 6468CC0857; Tue, 06 Jan 2026 12:07:15 +0100 (CET) Date: Tue, 6 Jan 2026 12:07:15 +0100 From: Willy Tarreau To: Thomas =?iso-8859-1?Q?Wei=DFschuh?= Cc: David Laight , Daniel Palmer , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] tools/nolibc: Add fread() to stdio.h Message-ID: References: <20260104083837.1390041-1-daniel@thingy.jp> <20260104083837.1390041-2-daniel@thingy.jp> <20260104183452.57213367@pumpkin> <20260105092729.386bac33@pumpkin> <20260105110142.127eaba3@pumpkin> <9c043cdd-499c-48ae-8b1c-e49d541a8b2b@t-8ch.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9c043cdd-499c-48ae-8b1c-e49d541a8b2b@t-8ch.de> On Tue, Jan 06, 2026 at 12:02:18PM +0100, Thomas Weißschuh wrote: > On 2026-01-05 11:01:42+0000, David Laight wrote: > > On Mon, 5 Jan 2026 18:43:03 +0900 > > Daniel Palmer wrote: > > > On Mon, 5 Jan 2026 at 18:27, David Laight 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. I agree with you. The lib's called "nolibc" for a reason: it's not a full-featured libc. Users have to accept some limitations. > The only real solution for partial writes that I see with the current > architecture is to limit the 'size' argument to '1'. I thought about this as well but I don't know if it will be more annoying than helpful... > 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... Let's see with the current patch how it goes. The first reported issues (if any) will help us lean in the most desirable direction. Willy