Hi Joey, Thanks a lot for moreutils - I'm a happy user via homebrew on macOS.
I recently hit a bug when spongeing a file >2GB and reported it to Debian's tracker with a suggested patch. Nicolas suggested I contact you via email as the bug is not reproducible on Debian. I've tested the path and it fixes the issue for me. Would be great if this could make it into the next release. Best wishes Cornelius On Mon, Sep 29, 2025 at 5:26 PM Nicolas Schier <[email protected]> wrote: > Hi Cornelius, > > On Sat, Sep 27, 2025 at 03:08:02PM +0200, Cornelius Roemer wrote: > > Package: moreutils > > Version: 0.67-1 > > Severity: normal > > Tags: patch, upstream > > > > On macOS (Darwin 64-bit), `sponge` fails when reading files of size ≥2 > GiB: > > > > $ truncate -s 2147483648 in > > $ cat in | sponge out > > sponge: failed to read from stdin: Invalid argument > > > > This happens because Darwin's `read(2)` system call rejects requests > > where `count > INT_MAX` (2,147,483,647), even though SSIZE_MAX is much > > larger on 64-bit. When sponge tries to read 2 GiB in a single call, > > `read()` fails with EINVAL. > > > > Linux accepts such large reads, so the issue only shows up on macOS and > > BSDs that impose the INT_MAX limit. > > > > Expected behavior: > > `sponge` should be able to handle arbitrarily large inputs, regardless > > of platform, by reading in chunks up to the maximum allowed size. > > > > Proposed fix: > > Limit the size of each `read()` call to `min(SSIZE_MAX, INT_MAX)`. > > I’ve written a patch which adds a small `safe_read()` helper and uses it > > in the two places where `sponge` reads input. > > > > Patch is attached: > > moreutils-e615f47-sponge: Fix "Invalid argument" error with 2GB+ files > on macOS.patch > > > > This has been tested on macOS Sonoma with 2–3 GiB files, and works > > correctly. The performance impact is negligible (<1 extra syscall per > > 2 GiB read). > > thanks for the bug report and the patch! > > As this is not reproducible with any Debian system: Would you mind > sending the patch directly to upstream (see README for the mail > address)? > > I could do that as well, but in case of detail discussions its probably > better if you can reply directly in case it's necessary. > > Kind regards, > Nicolas >
