Geoff Thorpe wrote: ....
I understand that, and if someone else is prepared to verify and assure themselves that the patch is acceptable, I won't object to them committing it. However, I don't *like* us committing more hacks when there are already too many, and your bug-report and patch provided a
I think you should at least commit the fix for BN_bn2dec as I think BN_bn2dec should not throw a core even if the format of the bignum is not optimal. Assume a->top == 1 and a->d[0] == 0 then
char *BN_bn2dec(const BIGNUM *a)
{
....
if ((t=BN_dup(a)) == NULL) goto err;
t == a
p=buf;
lp=bn_data;
if (t->neg) *(p++)='-';
if (t->top == 0)
t->top == 1
{
*(p++)='0';
*(p++)='\0';
}
else
{
i=0;
while (!BN_is_zero(t))
t == a == 0
{
*lp=BN_div_word(t,BN_DEC_CONV);
lp++;
}
lp--;
lp = bn_data - 1;
/* We now have a series of blocks, BN_DEC_NUM chars
* in length, where the last one needs truncation.
* The blocks need to be reversed in order. */
sprintf(p,BN_DEC_FMT1,*lp);
while (*p) p++;
while (lp != bn_data)
{
lp--;
sprintf(p,BN_DEC_FMT2,*lp);this would produce a core dump as lp points to some unallocated memory (note: BN_bn2hex and BN_print would simly print nothing (== '\0') in the above case).
Another question would be if both bignum representations for '0'
should be considered legal, i.e. is {{0, 0}, 0, 2, 0, 0} the same as
{{0, 0}, 1, 2, 0, 0} (BN_is_zero returns 1 for both representations
of '0') ?Nils
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
