1. rnd_reference was a duplication of the work the the engine
framework does, and wasn't ever checked. Removed.
2. use the NO_ macros to disable appropriate algorithms.
3. Only implement the RNG stuff if AEPRAND is defined (default: not
defined, because the AEP people plan on having boards without it.
I'll see if I can device a more dynamic way of disabling this).
4. aep_finish() now closes all connections, and if that worked, does a
proper finalize.
5. proper AEP types are used to conform to the AEP definitions of
their own functions.
6. remake the use of thread locks. The use of CRYPTO_LOCK_DYNLOCK was
definitely inappropriate, and for random generator stuff, it's
better to use CRYPTO_LOCK_RAND.
Also, I applied certain changes that were provided by the AEP people.
Among others, BN_CTX_new() is not used to initialise a BN context
(this was never done before, and may have made things slower or not
working at all.
1. some platforms do not have inttypes.h, and chasing them down
becomes ridiculous. Therefore, uint64_t can't be used for 64-bit
values.
2. some (other) platforms do not support "long long".
Solution: make AEP_U64 a struct with two longs unless long already is
64 bit long.
Also, restore all other types back to use unsigned char, unsigned int
and unsigned long. Make sure that AEP_U32 actually becomes 32 bits,
even on platforms where long is 64 bits (actually, we're just guessing
that int will stay at 32 bits on those...).
32-bit platforms. Instead, make use of inttypes.h and use the types
defined there to get 8-, 16-, 32- an 64-bit values.
There might be some operating systems where one should use int_types.h
instead of inttypes.h. Unfortunately, I don't recall which one(s).
make update
perl util/mkerr.pl -recurse -write -rebuild
(now, just look at the effect that last thing had on the ENGINE error
strings! How did that unbalance between macros and strings happen?)
