bn_correct_top() or bn_check_top() depending on debug settings. For
internal source, all bn_fix_top()s should be converted one way or the other
depending on whether the use of bn_correct_top() is justified.

For BN_div_recp(), these cases should not require correction if the other
bignum functions are doing their jobs properly, so convert to
bn_check_top().

ty to allocate anything at all.  This will allow eNULL to still work.

PR: 751
Notified by: Lutz Jaenicke

PR: 751
Notified by: meder@mcs.anl.gov
Reviewed by: Lutz Jaenicke, Richard Levitte

if the give size is 0.

This is a thought that came up in PR 751.

PR: #735
Submitted by: Tim Rice <tim@multitalents.net>

this and a few other changes.

(ie. where top may be zero, or it may be one if the corresponding word is
set to zero). Note, this only affects the macros in bn.h, there are probably
similar corrections required in some c files.

Also, clarify the audit-related macros at the top of the header. Mental
note: I must not forget to clean all this out before 0.9.8 is released ...

tolerance of ambiguous zero-representation, it just improves
BN_abs_is_word() and simplifies other macros that depend on it.

pseudo-random data for each bn_pollute().

functions.

PR: 755
Notified by: Jakub Bogusz <qboosh@pld-linux.org>

Therefore, change all instances of the symbol 'list' to something else.

PR: 758
Submitted by: Frédéric Giudicelli <groups@newpki.org>

PR: 768
Submitted by: Vadim Fedukovich <vf@unity.net>

that gets built before objects barfs all over the place because it
uses a new NID that hasn't had a chance of getting defined yet (in
this case, it was about a couple of new EC curves, and therefore a
couple of new corresponding NIDs).

I'm placing objects first in SDIRS!  There.

compared it to the amount of bits required...
PR: 770
Submitted by: c zhang <czhang2005@hotmail.com>

PR: 771
Submitted by: c zhang <czhang2005@hotmail.com>

PR: 732
Submitted by: Ilya Zakharevich <nospam-abuse@ilyaz.org>

Submitter's comment:

This patch:

a) Introduces a new file os2/backwardify.pl.

b) Introduces a new mk1mf.pl variable $preamble.  As you can see, it may
   be used also to move some OS-specific code to VC-CE too (the the
   first chunk of the patch);

c) The DESCRIPTION specifier of the .def file is made more informative:
   now it contains the version number too.  On OS/2 it is made conformant
   to OS/2 conventions; in particular, when one runs the standard command
	BLDLEVEL this.DLL
   one can see:

   Vendor:      www.openssl.org/
   Revision:    0.9.7c
   Description: OpenSSL: implementation of Secure Socket Layer; DLL for library crypto.  Build for EMX -Zmtd

   [I did not make Win32 descriptions as informative as this - I'm afraid to
    break something.  Be welcome to fix this.]

d) On OS/2 the generated DLL was hardly usable (it had a shared initialized
   data segment).

e) On OS/2 the generated DLLs had names like ssl.dll.  However, DLL names on
   OS/2 are "global data".  It is hard to have several DLLs with the same
   name on the system.  Thus this precluded coexistence of OpenSSL with DLLs
   for other SLL implementations - or other name clashes.  I transparently
   changed the names of the DLLs to open_ssl.dll and cryptssl.dll.

f) The file added in (a) is used to create "forwarder" DLLs, so the
   applications expecting the "old" DLL names may use the new DLLs
   transparently.  (A presence of these DLLs on the system nullifies (e),
   but makes old applications work.  This is a stopgap measure until the
   old applications are relinked.  Systems with no old applications do not
   need these DLLs, so may enjoy all the benefits of (e).)

   The new DLLs are placed in os2/ and os2/noname subdirectories.

g) The makefiles created with os2/OS2-EMX.cmd did not work (some mysterious
   meaningless failures).  The change to util/pl/OS2-EMX.pl uses the
   variable introduced in (b) to switch the Makefiles to SHELL=sh syntax.
   All these backslashes are removed, and the generated Makefiles started to
   work.

h) Running os2/OS2-EMX.cmd now prints out what to do next.

to apps.c, and give it the hopefully descriptive name parse_yesno().

PR: 777
Submitted by: Michael Shields <mshields@sunblocksystems.com>

rationale behind the move is that it's use by several applications.
The rationale behind the name change is that it describes what the
function does a bit better.

to 'openssl req' and 'openssl ca'.

PR: 779
Submitted by: Michael Bell <michael.bell@cms.hu-berlin.de>
Reviewed by: Richard Levitte

(there will be some follow-up changes)

PR: 780
Submitted by: Verdon Walker <VWalker@novell.com>
Reviewed by: Richard Levitte

against inconsistent BIGNUMs coming out of any of its API functions. So
this change no longer "fixes" the bn_print.c functions, but it makes for
cleaner code. This patch was a part of ticket 697.

PR: 697
Submitted by: Otto Moerbeek
Reviewed by: Geoff Thorpe

ticket 697 (though uses a different solution than the proposed one). This
problem was initially raised by Otto Moerbeek.

PR: 697
Submitted by: Nils Larsch
Reviewed by: Geoff Thorpe

optimizations.

Submitted by: Nils Larsch

PR: #778
Submitted by: George Mitchell <george@m5p.com>

and bn_add_words to avoid using fake bignums to window other bignums that
can lead to corruption. This change allows all bignum tests to pass with
BN_DEBUG and BN_DEBUG_RAND debugging and valgrind. NB: This should be
tested on a few different architectures and configuration targets, as the
bignum code this deals with is quite preprocessor (and assembly) sensitive.

Submitted by: Nils Narsch
Reviewed by: Geoff Thorpe, Ulf Moeller

sure the current length is used to calculate the new buffer length instead
of using the old length (prior to any variable substitution).

Submitted by: Nils Larsch

Max req -x509 use V1 if extensions section absent.

be modified to choose it instead of hpux64-parisc-gcc, which should
then be removed. hpux64-parisc-cc is removed already now as redundant
[in case you wonder, 64-bit HP-UX ABI *implies* PA-RISC2.0].

PR: 772

Submitted by: Kirill Kochetkov <kochet@ixbt.com>

PR: #748

which is used by BN_DEBUG_RAND
Submitted by: Nils Larsch

Submitted by: Goetz Babin-Ebell <babin-ebell@trustcenter.de>

PR: #766

Submitted by: Tim Rice <tim@multitalents.net>

PR: #735, #765

so don't run them if BN_DEBUG_RAND is defined.

Also, fix another small bug.

Submitted by: Nils Larsch

Keep it as is to avoid an API change, but check for negativ values.

Submitted by: Nils Larsch