bug#23110: seq apparent bug

[Ruediger Meier]

On Friday 08 April 2016, 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.
>
> > 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.

Hm, I think printing identical lines is a valid use case:
$ seq -f "%0.1f" 0 0.02 0.1
0.0
0.0
0.0
0.1
0.1
0.1

> That would 
> catch the seeming infinite loop (and at any rate, inadequate output)
> in this example.

I would check it before the loop like this

if ((first + inc) == first)
        /* exit error */ 


Note this still wouldn't catch this one
 seq 0 .0000000000000000000000000000001 1

But this would run millions of years anyway even if the increment would  
work and moreover maybe the user _wants_ an effective endless (non 
trivial) sequence like this
 seq 0 1 999999999999999999999999999999


> > 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++) ...'

I also guess that some people may have used this coreutils feature 
already in scripts:

# do nothing if inc = -1
for i in `seq 0 $inc 100`;do something; done

cu,
Rudi