Pádraig Brady <[email protected]> writes:
> On 12/11/2026 07:52, Collin Funk wrote:
>> Ideally, this would be two commits. One for the missing NEW_FILE_FLAG
>> check, and the other for the off-by-one. Given that the fixes are
>> small, I figured it would be more beneficial to keep each OSS scanner
>> issue related to one commit. I'm not 100% on it, though.
>> -- 8< --
>> * src/split.c (bytes_split): Don't lseek when the offset is already
>> at
>> the correct position from reading. Don't add 1 to TO_WRITE.
>> * tests/split/filter.sh: Add two test cases.
>> * NEWS: Mention the bug fixes.
> The triggers for the two bugs are the same,
> so I'd keep it as one commit (it is close though).
>
> I was wondering why 256k was chosen given we've control
> over ---io-blksize in split(1), but I think it's due to
> default pipe size, so that we write enough to get EPIPE.
> There doesn't seem to be a way to determine default pipe size.
> We could add a value to getlimits, and use F_GETPIPE_SZ on Linux,
> but I think FreeBSD starts at 16K and grows to 64K as needed,
> so its probably not worth querying it for now.
> So just a comment along the lines of the following would be useful:
>
> # Using 256K which is usually enough to fill a pipe buffer
> # so that split(1) has to handle the EPIPE.
>
> Otherwise LGTM.
Yes, thats right.
There is this note in my recent changes to sort-compress-hang.sh:
# FIXME: This assumes the input file is larger than the default pipe size.
While writing that patch and this one, I was considering adding a
function to init.cfg that checked the default pipe size using this:
$ true | pipesz --get | cut -f2
65536
Falling back to a reasonable guess where util-linux isn't installed. But
it wasn't obvious to me that it was worth the effort.
Collin
