supporting threads, which means that th assertion is supperbly
dangerous, so make sure it's not compiled under Win32, period.

it wants to stir the pool using ssleay_rand_add.  This fix provides the
possibility to call ssleay_rand_add inside a locked state by simply telling
it not to do any locking through a static variable.  This isn't the most
elegant way one could do this, but it does retain thread safety during the
stirring process.

rand_lcl.h

today.  Time to add extra info so the poor users know where to
go with their troubles.

They have nothing to do with the particular PRNG (md_rand.c).

variables are locked.

it's a good thing if ssleay_rand_status() would do the corresponding
lock and unlock as everyone else...

on Win32.

because this will drain the entropy pool.

instead of 'unsigned' counters.
Seed PRNG in MacOS/GetHTTPS.src/GetHTTPS.cpp.

Partially submitted by Yoram Meroz <yoram@mail.idrive.com>.

Slightly clarify the RAND_... documentation.

are not guaranteed to be unpredictable.

and re-enable seeding with more data than read from DEVRANDOM -- just
don't pretend it contains entropy.

returns int (1 = ok, 0 = not seeded). New function RAND_add() is the
same as RAND_seed() but takes an estimate of the entropy as an additional
argument.

don't try to detect fork()s by looking at getpid().
The reason is that threads sharing the same memory can have different
PIDs; it's inefficient to run RAND_seed each time a different thread
calls RAND_bytes.

between SSLeay 0.8.1b and 0.9.0b with no apparent reason).
If we *want* an error when DEVRANDOM is not defined (it always is with
the current e_os.h) we should use #error.

This will soon be complemented with MacOS specific source code files and
INSTALL.MacOS.

I (Andy) have decided to get rid of a number of #include <sys/types.h>.
I've verified it's ok (both by examining /usr/include/*.h and compiling)
on a number of Unix platforms. Unfortunately I don't have Windows box
to verify this on. I really appreciate if somebody could try to compile
it and contact me a.s.a.p. in case a problem occurs.

Submitted by: Roy Wood <roy@centricsystems.ca>
Reviewed by: Andy Polyakov <appro@fy.chalmers.se>

in cryptlib.h (which is often included as "../cryptlib.h"), then the
question remains relative to which directory this is to be interpreted.
gcc went one further directory up, as intended; but makedepend thinks
differently, and so probably do some C compilers.  So the ../ must go away;
thus e_os.h goes back into include/openssl (but I now use
#include "openssl/e_os.h" instead of <openssl/e_os.h> to make the point) --
and we have another huge bunch of dependency changes.  Argh.

There were problems with putting e_os.h just into the top directory,
because the test programs are compiled within test/ in the "standard"
case in in their original directories in the makefile.one case;
and in the latter symlinks may not be available.

include file.