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.
thanks,
Padraig
