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. 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_ Removal of the --width limitation is a real improvement, so worth mentioning in NEWS as you've done. thanks! Padraig
