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.
b2abaf2265