might overflow.

Improve readability of bn_shift.c.

Add comment in bn_lib.c (why zero data between top and max?)

Change bntest.c output for BN_kronecker test

I'm still investigating what caused the segementation fault
(maybe "make clean; make" will cure it ...).
But BN_bin2bn should always reset ret->neg.

This caused a segmentation fault in calls to malloc, so I cleaned up
bn_lib.c a little so that it is easier to see what is going on.
The bug turned out to be an off-by-one error in BN_bin2bn.

"make update"

two functions that did expansion on in parameters (BN_mul() and
BN_sqr()).  The problem was solved by making bn_dup_expand() which is
a mix of bn_expand2() and BN_dup().

symbols for debugging are defined.

Fix warnings with BIO_dump_indent().

like Malloc, Realloc and especially Free conflict with already existing names
on some operating systems or other packages.  That is reason enough to change
the names of the OpenSSL memory allocation macros to something that has a
better chance of being unique, like prepending them with OPENSSL_.

This change includes all the name changes needed throughout all C files.

temporary BIGNUMs. BN_CTX still uses a fixed number of BIGNUMs, but
the BN_CTX implementation could now easily be changed.

file from a bio or fp. Added some more constification to the BN library.

This also avoids the problems with SC4.2 and unpatched SC5.

Submitted by: Andy Polyakov <appro@fy.chalmers.se>

Submitted by: Richard Levitte <richard@levitte.org>

when they cause the destination to expand.

To see how evil this is try this:

#include <pem.h>
main()
{
	BIGNUM *bn = NULL;
        int i;
	bn = BN_new();
	BN_hex2bn(&bn, "FFFFFFFF");
	BN_add_word(bn, 1);
	printf("Value %s\n", BN_bn2hex(bn));
}

This would typically fail before the patch.

It also screws up if you comment out the BN_hex2bn line above or in any
situation where BN_add_word() causes the number of BN_ULONGs in the result
to change (try doubling the number of FFs).

1. The already released version was 0.9.1c and not 0.9.1b

2. The next release should be 0.9.2 and not 0.9.1d, because
   first the changes are already too large, second we should avoid any more
   0.9.1x confusions and third, the Apache version semantics of
   VERSION.REVISION.PATCHLEVEL for the version string is reasonable (and here
   .2 is already just a patchlevel and not major change).
tVS: ----------------------------------------------------------------------