[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Integer Overflow in braces

From: Dan Douglas
Subject: Re: Integer Overflow in braces
Date: Tue, 18 Aug 2015 08:12:39 -0500
User-agent: KMail/5.0.41 alpha1 (Linux/4.2.0-rc7; KDE/5.14.0; x86_64; ; )

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 
> > the question of whether the resulting expansion is "too big". Code that 
> > 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 
Dan Douglas

reply via email to

[Prev in Thread] Current Thread [Next in Thread]