insecure, so a static lock is added to isolate the sensitive parts.
Also, to avoid one thread freeing a lock that is used by another, a
reference counter is added.

any more.

be needed in some ENGINE code, and might serve elsewhere as well.
Note that it's implemented in such a way that the locking itself is
done through the same CRYPTO_lock function as the static locks.

WARNING: This is currently experimental and untested code (it will get
tested soon, though :-)).

type-specific stack function.  Second, even when we don't build any of
those functions, DECLARE_STACK_OF lines should not find themselves
into $def.

sk_whatever_insert and sk_whatever_set immediately reveals the subtle
difference in parameter order.

Change mkstack.pl so that safestack.h is not rewritten when
nothing has changed.

After some messing around this seems to work but needs
a few more tests. Working out the syntax for sk_set_cmp_func()
(cast it to a function that itself returns a function pointer)
was painful :-(

Needs some testing to see what other compilers think of this
syntax.

Also needs similar stuff for ASN1_SET_OF etc etc.

As far as I understand, it still needs to be compiled on NT...
Contributed by Arne Ansper <arne@ats.cyber.ee>

label. (Reported by Alexei Bakharevski.)

"symbols" including functions (of all prototypes( and variables. Whilst
casting any function type to another violates ANSI C (I believe), it is
a necessary evil in shared-library APIs. However, it is quite
conceivable that functions in general and data symbols could very well
be represented differently to each other on some systems, as Bodo said;

> Since the function/object distinction is a lot more likely to be
> important on real-life platforms supporting DSO *and* it can be quite
> easily done *and* it will silence compilers that don't like
> assignments from void pointers to function pointer variables, why
> not do it?

I agree. So this change splits the "dso_bind" handler in DSO_METHOD
into "dso_bind_var" and "dso_bind_func". Similarly the exported
function DSO_bind() has been split in two. I've also put together
changes for the various DSO_METHOD implementations, but so far only
DSO_dlfcn() has been tested. BTW: The prototype for dso_bind had been
a bit strange so I've taken the opportunity to change its shape (in
both variations).

Also, the README has been updated - particularly with a note about
using customised native name-translation for shared libraries (and that
you can't do it yet).

Reported by Robert Eiglmaier <robert.eiglmaier@ixos.de>

when symlink() fails.

BN_mod_exp_atalla could be used.

BN_mod_exp. Call the regular atalla mod_exp operation instead.

Also, "make update" has added some missing functions to libeay.num,
updated the TABLE for the alpha changes, and updated thousands of
dependancies that have changed from recent commits.

Documentation correction.

EVP_DecryptInit() return values.

Update docs.

to support multiple calls.

New function to retrieve email address from certificates and
requests.

as expected -- maybe it's the different processor, maybe my
previous timings were too inaccurate.

Don't give performance gain estimates that appear to be more precise
than they really are, especially when they are wrong
(2/(1/1.15 + 1) = ca. 1.0698).

was a really bad idea.  For example, the following:

	#include <x509.h>
	#include <bio.h>
	#include <asn1.h>

would make sure that things like ASN1_UTCTIME_print() wasn't defined
unless you moved the inclusion of bio.h to above the inclusion of
x509.h.  The reason is that x509.h includes asn1.h, and the
declaration of ASN1_UTCTIME_print() depended on the definition of
HEADER_BIO_H.  That's what I call an obscure bug.

Instead, this change makes sure that whatever header files are needed
for the correct process of one header file are included automagically,
and that the definitions of, for example, BIO-related things are
dependent on the absence of the NO_{foo} macros.  This is also
consistent with the way parts of OpenSSL can be excluded at will.

says one should use.

marginally faster BN_mod_exp for 1024 bit exponents.

because we're only handling words anyway) in BN_mod_exp_mont_word
making it a little faster for very small exponents,
and adjust the performance gain estimate in CHANGES according
to slightly more thorough measurements.
(15% faster than BN_mod_exp_mont for "large" base,
20% faster than BN_mod_exp_mont for small base.)

it is expected).