bug#23110: seq apparent bug

[Bernhard Voelker]

On 04/08/2016 09:45 PM, Paul Eggert wrote:
> On 04/08/2016 05:57 AM, Pádraig Brady wrote:
>> Do we want to deal with these cases spinning the cpu,
>> in further patches?
>>
>>    seq 1 nan 1
> 
> NaN should be an error in any of the operands.

+1

>> seq 1 .0000000000000000000000000000001 1
> 
> For this I suggest the following heuristic. When inferring a format that 
> would apply to two or more lines of output, try formatting the first two 
> lines and report an error if they are the same. That would catch the 
> seeming infinite loop (and at any rate, inadequate output) in this example.

The only way to avoid this at all is to extend seq_fast() also for arbitrary
numbers, i.e., re-write the code to do the math all in the string format the
user wants.

Today, it's hard to explain why "seq 1 1 100000000" needs only 0.6s while
"seq 1 2 100000000" takes 24s although the increment is doubled.  Okay, one
could extend fast_seq() to work for all_digits_p(step).  As it only the
plus operation (or minus, well), wouldn't it be faster to manually calculate
all as strings, no matter if step is 1 or 0.00000000000000000000000000123?
Besides, the output could be buffered to save writes.

>> As an aside, I see FreeBSD requires the STEP to be in the right direction
>> when FIRST != LAST, or it will also exit with error.
>> GNU will just output nothing in that case. 
> 
> Outputting nothing sounds better. 'seq 1 0' is like 'for (i = 1; i <= 0; 
> i++) ...'

+1

Have a nice day,
Berny