Pádraig Brady <[email protected]> writes: > On 26/10/2026 03:45, Collin Funk wrote: >> Currently, the following occurs: >> $ od -v -t x1 -j $((INTMAX_MAX - 1)) /dev/zero >> 777777777777777777776 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> Segmentation fault (core dumped) od -v -t x1 -j $((INTMAX_MAX - >> 1)) /dev/zero >> This is because the signed integer overflows, becoming negative, >> before >> being used in format_address_std to create a printable string. >> The bug was "introduced" by commit 35d9bf691 (od: prefer idx_t to >> size_t, 2025-06-24), but the previous behavior would still be a bit >> wonky. That is, the offset would eventually overflow, but since it was >> unsigned, it would wrap around and start printing from address zero >> again. >> For that reason, I marked the specific instance invocation as a bug, >> but >> mentioned the general improvement as well. I'm not 100% sure that is the >> best way to document it, though. > The fix looks good. > I'd have a single bug fix entry in NEWS along the lines of: > > od now exits gracefully when offsets overflow integer limits. > [This bug was present in "the beginning".]
Thanks, I pushed with that adjustment. > While thinking about this, some ideas for potential further changes in this > area, > probably not be worth doing due to the practicality of hitting these limits: > > - Double the supported offset range using unsigned. > - Decouple -N and -j handling. > - Avoid offset calculations with -An. > - Allow offset wrap, with a diagnostic to stderr. My feeling was that generally there isn't much of a point in continuing if you can't get any useful input. Perhaps unsigned would be better, but file sizes larger than can fit into off_t seem like they are bound to run into trouble. Collin
