From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from todd.t-8ch.de (todd.t-8ch.de [159.69.126.157]) (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 5319A31AAAA for ; Tue, 6 Jan 2026 11:02:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=159.69.126.157 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767697344; cv=none; b=tJTfBkPMBQUH2+8FIz5rNRYMx2zuEE8B9fOC0ERTvj2bAYoxCqR/SmjHCY6goTSGkWpUMra46NL9IqHYH+A/gEu6n2q2k7D6KfdFM6eJVyPg9b9HxEIprhfE4LyiaZyg8Tj+BBPhm6v2DI8/VSFn2/pfO5MQ9uJG6Kn9tNdLEJs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767697344; c=relaxed/simple; bh=PoT4mgRoZk5X6UPIowLgi52RdfWWndusMbT+Rq4aoZM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qR3rSQUCrqB1dqpbX4f2fl5D8rHPDiVA2EFpHhPdGNMn2k2r7ZXFg24lw0IA7ZlSoqlCtZDZOjxNIzGo4mYsjTsFD23ignWdG1YViz+isVhBDHxgAYDG8PadGMMI4hETdyV301uamKCZ2lFdqbtvB0WnZqzLc3jj83nMjODjPRo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=weissschuh.net; spf=pass smtp.mailfrom=weissschuh.net; dkim=pass (1024-bit key) header.d=weissschuh.net header.i=@weissschuh.net header.b=hu6elLIj; arc=none smtp.client-ip=159.69.126.157 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=weissschuh.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=weissschuh.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=weissschuh.net header.i=@weissschuh.net header.b="hu6elLIj" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=weissschuh.net; s=mail; t=1767697339; bh=PoT4mgRoZk5X6UPIowLgi52RdfWWndusMbT+Rq4aoZM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hu6elLIjB+etGBrxyyWKElIGyMNcgdgm0+6sEoHWgpHtpzBN9F1ydL1DdDZxOsJDr fNY04tOPnJ3whnHuSUeIBIhCmGPLm0elbuJAg1PBGuN7W7MTkosbv52aQtqc690yx7 j1p8xC5qByPnoJdHV91O6PEGf5z2+JDmB3F5GnFs= Date: Tue, 6 Jan 2026 12:02:18 +0100 From: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= To: David Laight Cc: Daniel Palmer , w@1wt.eu, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] tools/nolibc: Add fread() to stdio.h Message-ID: <9c043cdd-499c-48ae-8b1c-e49d541a8b2b@t-8ch.de> References: <20260104083837.1390041-1-daniel@thingy.jp> <20260104083837.1390041-2-daniel@thingy.jp> <20260104183452.57213367@pumpkin> <20260105092729.386bac33@pumpkin> <20260105110142.127eaba3@pumpkin> 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=us-ascii Content-Disposition: inline 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 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. 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