Re: standards/60663: POSIX.1-2024: dd(1) options

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR standards/60663; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: standards/60663: POSIX.1-2024: dd(1) options
Date: Sat, 29 Aug 2026 01:08:29 +0700

     Date:        Fri, 28 Aug 2026 16:50:00 +0000 (UTC)
     From:        "campbell+netbsd%mumble.net@localhost via gnats" <gnats-admin%NetBSD.org@localhost>
     Message-ID:  <20260828165000.8F95A1A923E%mollari.NetBSD.org@localhost>
 
 
   | 	if I understood correctly after 6sec of reading and thinking
   | 	-- when combined with bs=N is equivalent to our ibs=N obs=N
 
 No, not that, those always do ibs=N sized reads, then if needed rebuffer
 whatever is obtained into obs=M sized pieces  (ibs and obs are POSIX
 options as well ... given that they have been in dd since forever).
 
 iflags=fullblock is intended to cause dd to read the complete N bytes
 from ibs=N before doing any other processing (unless EOF occurs, what
 happens on a read error in this case is, very thoughtfully, forgotten)
 That means, first read request is for N bytes, then if n, less than N,
 were received, another read for N-n bytes, and so on, until all N bytes
 are received.
 
 ie: no longer are all read requests for N bytes; hence this would be useless
 reading from a tape drive, and pointless reading from a file - but might
 make sense reading from a TCP connection, and perhaps from a pipe.
 
 The fullblock processing can be used with bs= or with ibs=/obs=  -- it really
 just hides data sources that can deliver the data piecemeal, rather than in
 nice pre-prdained blocks all at once ... so much so, that however many
 read()s are needed to fill the input block size (from bs, or ibs) still
 counts as 1 record read for the purposes of count= and the reports.