Richard Levitte [Sun, 9 Apr 2000 12:04:35 +0000 (12:04 +0000)]
I've always wanted to make the CONF library more adaptable. Here's
the result.
I have retained the old behavior of the CONF_* functions, and have
added a more "object oriented" interface through NCONF_* functions
(New CONF, you see :-)), working the same way as, for example, the
BIO interface. Really, the CONF_* are rewritten so they use the
NCONF_* functions internally.
In addition to that, I've split the old conf.c code into two files,
conf_def.c and conf_api.c. conf_def.c contains the default config
object that reads a configuration file the standard OpenSSL way, as
well as configuration file with Win32 registry file syntax (I'm not
sure I got that one right). conf_api.c provides an API to build other
configuration file readers around (can you see a configuraion file in
XML? I can :-)).
Finally, I've changed the name conf_lcl.h to conf_def.h, since it's
made specifically for that "class" and none others.
I forgot about $openssl_other_defines ... should probably do this
for consistency. Not sure though whether HAVE_DLFCN_H should be
included too? If we go the autoconf route then this probably wouldn't
be included.
This helps make the DSO stuff more portable;
* "no-dso" option available in Configure so that all DSO methods will
return NULL, overriding any support the platform might otherwise
have built.
* dlfcn_no_h config string now available rather than just dlfcn. This
is for platforms that have dlfcn.h functions but do not have (or
need) the dlfcn.h header file.
This commit ties the new DSO code (crypto/dso/) into the build for a
variety of platforms. A few are missing, and they will be added in
eventually, but as this is new stuff, it was better to not break lots of
platforms in one go that we can't easily test. The changes to "Configure"
should illustrate how to add support to other systems if you feel like
having a go.
NB: I'll add something shortly to allow you to add "dlfcn.h" support on
those platforms that don't have (or need) a dlfcn.h header file. (The
symbol for Configure will probably by "dlfcn_no_h").
Thanks to Richard Levitte, who is responsible for the dso_dl.c support,
understanding the trickier aspects of the build process, and giving great
feedback on everything else.
[Don't use this stuff if you're easily offended by changes to the
interface or behaviour - it's still work in progress.]
This is a set of startup code for the DSO support, it's not yet linked into
the build process (an upcoming commit no doubt), and is very much *new*
code - what that means is that it compiles ok - usually. It certainly
doesn't mean it runs well or even properly yet. Please don't muck round
with this unless you're looking to help out and hunt bugs. :-)
Currently this code doesn't have any support for controlling the "load"
behaviour (eg. paths, filename translations, etc). That'll be handled
using DSO_ctrl() and various flags, once we work out a sensible set of
flags.
Richard Levitte [Wed, 29 Mar 2000 17:25:52 +0000 (17:25 +0000)]
Since ssleay_rand_initialize() unlocks then locks CRYPTO_LOCK_RAND,
it's a good thing if ssleay_rand_status() would do the corresponding
lock and unlock as everyone else...
Richard Levitte [Sun, 19 Mar 2000 09:35:19 +0000 (09:35 +0000)]
Change the notation and coding of the version to be able to contain
both a patch level and a beta status. IMHO, it also makes more sense
to have beta status be part of the development status than to have it
be an alternate name for patch levels under special conditions.
Ulf Möller [Sun, 19 Mar 2000 02:06:37 +0000 (02:06 +0000)]
des_quad_cksum() byte order bug fix.
See http://www.pdc.kth.se/kth-krb/
Their solution for CRAY is somewhat awkward.
I'll assume that a "short" is 32 bits on CRAY to avoid the
#ifdef _CRAY
typedef struct {
unsigned int a:32;
unsigned int b:32;
} XXX;
#else
typedef DES_LONG XXX;
#endif