[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#7214: sort --debug maps large old-style field number to 0 in diagnos
bug#7214: sort --debug maps large old-style field number to 0 in diagnostic
Thu, 14 Oct 2010 09:48:52 -0700
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20100915 Thunderbird/3.0.8
On 10/14/10 05:44, Jim Meyering wrote:
>> *val = SIZE_MAX;
>> > + if (debug) /* Note --debug must come before keys to diagnose this.
>> > */
>> > + error (0, 0, _("%" PRIuMAX " is too large, using %zu"), n, *val);
> That does sound like an improvement (that would require comment changes),
No, it's better to silently treat large field numbers as if they were infinity.
'sort' already does that in other cases (e.g., specify_nthreads),
and so does 'join' (e.g., string_to_join_field), and we should
be doing that whenever possible.
The idea is that, since 'sort' can't possibly represent a line that
contains more than SIZE_MAX fields, it's correct to treat very large
field numbers, even numbers that provoke LONGINT_OVERFLOW, as if they
were SIZE_MAX. GNU code should not contain arbitrary limits: so
when it's correct to substitute a representable number for a
number that's so large that it's unrepresentable, we should do that
instead of reporting an overflow and failing.