Re: Integer Overflow in braces

[Dan Douglas]

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