GNU bug report logs - #23110
seq apparent bug

Previous Next

Full log

Message #38 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ruediger Meier <sweet_f_a <at> gmx.de>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#23110: seq apparent bug
Date: Fri, 8 Apr 2016 22:51:54 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.