.DLL, in particular static build. The issue has been discussed in RT#1230
and later on openssl-dev, and mutually exclusive approaches were suggested.
This completes compromise solution suggested in RT#1230.
PR: 1230
knock-on work than expected - they've been extracted into a patch
series that can be completed elsewhere, or in a different branch,
before merging back to HEAD.
For those, unless the environment variables RANDFILE or HOME are
defined (the default case!), RAND_file_name() will return NULL.
This change adds a default HOME for those platforms.
To add a default HOME for any platform, just define DEFAULT_HOME in
the proper place, wrapped in appropriate #ifdef..#endif, in e_os.h.
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.
(they don't really exist before version 7), so that solution was toast.
Instead, let's do it the way it's done on Unix, but then remove older
versions of the file.
That new mechanism *may* fail for some unixly formated file spec,
although I wouldn't worry too much about it.
this is what we now use to read $RANDFILE / $HOME/.rnd.
(Previously, after 'cat'ting lots of stuff into .rnd
only the first MB would be looked at.)
Bugfix for apps/enc.c: Continue if RAND_pseudo_bytes returns 0
(only -1 is an error).
opening the output file with "wb" to truncate it except on VMS
(where the file now keeps its original length because it is opened
with "rb+" -- does VMS have ftruncate?)
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.
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.
Andy Polyakov
Geoff Thorpe
Ben Laurie
Lutz Jänicke
Richard Levitte
Bodo Möller
Ulf Möller