On Tuesday, August 18, 2015 09:04:33 AM Greg Wooledge wrote:
> On Tue, Aug 18, 2015 at 07:54:48AM -0500, Dan Douglas wrote:
> > IMHO the issue of whether the integer is allowed to overflow is separate
from
> > the question of whether the resulting expansion is "too big". Code that
does
> > an `eval "blah{0..$n}"` is reasonably common and not necessarily stupid.
>
> Yes, that's fine. But I don't actually understand what kind of overflow
> Pasha K was actually trying to test for. He/she mentioned "nelem", which
> only appears in two places in the bash source code: once in indexed
> arrays, and once in associative arrays. But there were no arrays in
> the script being executed.
>
> {0..9999999999999999} should produce an error because it runs out of
> memory. So I would expect to see a malloc failure, or something similar.
> If Pasha is saying that an integer overflow occurs before the malloc
> failure, then that may or may not be interesting to Chet. If it crashes
> bash, then it's not interesting to me, because the inevitable malloc
> failure would have crashed it if the overflow didn't. It only becomes
> interesting to me if the integer overflow causes some weird behavior to
> happen BEFORE bash crashes.
>
Actually I think I spoke too soon. There's already some considerable logic in
braces.c to check for overflow (e.g. around braces.c:390 shortly after
declaration of the int). Looks like there were some changes in this code last
year to "beef it up" a bit. (see commit
67440bc5959a639359bf1dd7d655915bf6e9e7f1). I suspect this is probably fixed in
devel.
--
Dan Douglas
