I think Todd is right, and this doesn't need to change.
Todd C. Miller wrote:
> On Sun, 12 Dec 2021 19:15:51 -0600, Scott Cheloha wrote:
>
> > cat(1) sizes its I/O buffer according to the st_blksize of the first
> > file it processes. We don't do this very often in the tree. I'm not
> > sure
On Sun, 12 Dec 2021 19:15:51 -0600, Scott Cheloha wrote:
> cat(1) sizes its I/O buffer according to the st_blksize of the first
> file it processes. We don't do this very often in the tree. I'm not
> sure if we should trust st_blksize.
It sizes the buffer based on st_blksize of stdout, not the
On Mon, Dec 13, 2021 at 02:52:50AM -0600, Scott Cheloha wrote:
> > On Dec 13, 2021, at 01:13, Otto Moerbeek wrote:
> >
> > On Sun, Dec 12, 2021 at 07:15:51PM -0600, Scott Cheloha wrote:
> >
> >> cat(1) sizes its I/O buffer according to the st_blksize of the first
> >> file it processes. We do
> On Dec 13, 2021, at 01:13, Otto Moerbeek wrote:
>
> On Sun, Dec 12, 2021 at 07:15:51PM -0600, Scott Cheloha wrote:
>
>> cat(1) sizes its I/O buffer according to the st_blksize of the first
>> file it processes. We don't do this very often in the tree. I'm not
>> sure if we should trust st_b
On Sun, Dec 12, 2021 at 07:15:51PM -0600, Scott Cheloha wrote:
> cat(1) sizes its I/O buffer according to the st_blksize of the first
> file it processes. We don't do this very often in the tree. I'm not
> sure if we should trust st_blksize.
>
> It would be simpler to just choose a value that w
cat(1) sizes its I/O buffer according to the st_blksize of the first
file it processes. We don't do this very often in the tree. I'm not
sure if we should trust st_blksize.
It would be simpler to just choose a value that works in practice and
always use it.
64K works well. We settled on that f