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