Pádraig Brady <[email protected]> writes: > On 16/09/2025 05:51, Collin Funk wrote: >> An oversight in my multi-byte fold changes was that I did not consider >> characters with a width of zero. Here is an easy way to see the issue: >> $ ./src/fold /dev/zero >> Segmentation fault (core dumped) >> The first patch fixes that by printing the output buffer if the >> current >> character cannot fit in it and the current column is less than the fold >> width (i.e. the unlikely case of many zero width characters). It also >> adds a test using /dev/zero and U+200B ZERO WIDTH SPACE. >> The use of 'fold /dev/zero' is really a more specific case of fold >> operating on very long lines. In all previous versions before the >> multi-byte changes this can exhaust the systems memory only if --width >> is large: >> $ timeout 60 valgrind ~/fold-9.7 --width=$((1 << 62)) /dev/zero >> ==2105553== in use at exit: 2,122,618,116 bytes in 51 blocks >> I added a note about that in NEWS since it is a nice change, despite >> it >> being highly unlikely anyone does this. >> Patch 3 corrects the wording to state this only happens if a large >> --width is given. > > Excellent. > > Note NEWS should only mention changes in released versions, > so patch 2 should not be applied. Released upstream coreutils > has only ever used getc() so far.
Yep, my mistake. > I see the test uses $(cat out | wc -l), > while $(wc -l < out) is more idomatic. > > The `yes | ... > inp` should be protected by || framework_failure_ Thanks for this and the other fixes. Collin
