On 10/11/2026 04:36, Collin Funk wrote:
Pádraig Brady <[email protected]> writes:
+ /* A single read() may return only part of a character, e.g., from a pipe
+ or terminal. Keep reading until the character at the current offset
+ is complete, or enough bytes are available to decide, or at EOF.
+ Note mcel_scan does not distinguish invalid from incomplete sequences,
+ so invalid bytes can also cause further reads and delay output. */
+ while (0 < available && available < MCEL_LEN_MAX && ! mbbuf->eof)
{
mcel_t g = mcel_scan (mbbuf->buffer + mbbuf->offset,
mbbuf->buffer + mbbuf->length);
- if (g.err)
- return mbbuf_topup (mbbuf);
+ if (! g.err)
+ break;
+ available = mbbuf_topup (mbbuf);
}
I see. So my original mbbuf implementation would handle this correctly,
since it used fread, but that would also delay in cases where it wasn't
needed or desired. Your changes in 9.11 made it not delay, but they
missed this one specific case where delaying is more desirable than
missing a multibyte character split across reads, e.g., because the
writer is slow. Do I understand that correctly?
Exactly.
Assuming I understand correctly, then both changes look good to me. When
applying the patches using 'git am', though, the commit-msg hook failed
for me. The first patch failed with:
# commit-msg: line length (74) greater than than max: 72
I fixed it by splitting the command across multiple lines here:
$ yes $(yes éééááé | head -n9 | paste -s -d，) \
| head -n1M > mb.in
Oh interesting. Can you confirm you have commit v9.0-47-ga2b21e910 installed.
The second one failed with:
# commit-msg: invalid first word(s) of summary line: , ,
I fixed it by removing the spaces in the first line of the commit:
I don't know why my commit hook allowed that.
Perhaps I inadvertently used git commit -n.
cut,expand,fold,unexpand: fix handling of multi-byte with short reads
I don't see why either shouldn't be allowed. I'll take a look at the hook.
I wouldn't bother allowing variants there TBH.
cheers,
Padraig
