On Linux, Bash is fine if you don't mind your package builds spending 50% of

their time compiling, and 50% spinning in shell scripts.  If you'd rather
spend your power bill on useful gcc cycles though, you might desire to use a
different shell for running build scripts - like pdksh, which is conveniently
available at bootstrap time.

But what if pdksh does this to you?

pdksh -c 'f=`pdksh -c set | wc -l`; f=$((f+1)); while ((f < 100000)); do f=$((f+1)); eval "v_${f}=0"; echo "$f"; done'|tail -1
 13106
segmentation fault (core dumped)  pdksh -c

Well that's annoying, isn't it.

% echo $(((13106*10+7)/8))
16383

... that's a magical number.  Coincidence?  Well, no.

tp->nfree = 8*nsize/10; /* table can get 80% full */

This particularly ugly overflow happens because tp->size is a short.  When
texpand() does:

  p = &ntblp[hash(tblp->name) & (tp->size-1)];

tp->size-1 will, given enough variables (80% of 2^15), type coerce into a
sign-extended 32-bit value of:

info registers $ecx
ecx            0xffff7fff       -32769

That hash() function does more or less what you guess, it's a 32 bit unsigned
value.  The chances of the final pointer pointing inside the valid allocated
block of memory are very low indeed.

The least-change solution is to change tp->size to a 32 bit value.  I've left
it signed because that matches, for example, the size parameter passed to
texpand().  But really this code would be more correct with a liberal
sprinkling of "unsigned", and perhaps a bit of "size_t".

This change allows ffmpeg's configure script, as interpreted by pdksh, to
produce more usable output than a core file.

Bump PKGREVISION for code change.

0 files changed, 0 insertions, 0 deletions