- Apr 26, 2000
-
-
Richard Levitte authored
-
Richard Levitte authored
-
- Apr 25, 2000
-
-
Geoff Thorpe authored
if a DSO_load(NULL,...) operation fails, it will have to call DSO_free() on the DSO structure it created and that will filter through to this "unload" call. If the stack size is "< 1", then the library never actually loaded. To keep things clean higher up, I'll treat this as a vacuous case without an error. It makes the error stack easier to follow real world cases, and the error this ignores was only useful for catching bugs in internal code, not mismatched calls from applications (which should be handled in the generic DSO layer).
-
- Apr 20, 2000
-
-
Geoff Thorpe authored
with RSA_METHOD (the **_get_default_methods do set the default value if it's not set). However, the code had some duplication and was a bit conter-intuitive.
-
Geoff Thorpe authored
initialised, at which point an appropriate default was chosen. This meant a call to RSA_get_default_method might have returned FALSE. This change fixes that; now any called to RSA_new(), RSA_new_method(NULL), or RSA_get_default_method() will ensure that a default is chosen if it wasn't already.
-
- Apr 19, 2000
-
-
Geoff Thorpe authored
-
Geoff Thorpe authored
technique used is far from perfect and alternatives are welcome. Basically if the translation flag is set, the string is not too long, and there appears to be no path information in the string, then it is converted to whatever the standard should be for the DSO_METHOD in question, eg; blah --> libblah.so on *nix, and blah --> blah.dll on win32. This change also introduces the DSO_ctrl() function that is used by the name translation stuff.
-
- Apr 15, 2000
-
-
Bodo Möller authored
-
- Apr 14, 2000
-
-
Bodo Möller authored
-
Bodo Möller authored
-
- Apr 12, 2000
-
-
Bodo Möller authored
-
Richard Levitte authored
-
- Apr 10, 2000
-
-
Richard Levitte authored
-
- Apr 09, 2000
-
-
Richard Levitte authored
-
Richard Levitte authored
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.
-
- Apr 06, 2000
-
-
Bodo Möller authored
-
Bodo Möller authored
-
Bodo Möller authored
-
Bodo Möller authored
-
Geoff Thorpe authored
-
Geoff Thorpe authored
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.
-
Geoff Thorpe authored
* "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.
-
- Apr 04, 2000
-
-
Geoff Thorpe authored
-
Geoff Thorpe authored
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.] PR:
-
Geoff Thorpe authored
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.
-
Bodo Möller authored
-
- Apr 01, 2000
-
-
Richard Levitte authored
-
Richard Levitte authored
as important to keep a low profile here :-))
-
Richard Levitte authored
a low profile, so we don't get discontinuity in the numbering...)
-
Richard Levitte authored
-
Richard Levitte authored
-
Richard Levitte authored
off.
-
- Mar 30, 2000
-
-
Bodo Möller authored
-
Bodo Möller authored
variables are locked.
-
Dr. Stephen Henson authored
-
- Mar 29, 2000
-
-
Richard Levitte authored
it's a good thing if ssleay_rand_status() would do the corresponding lock and unlock as everyone else...
-
- Mar 28, 2000
-
-
Ulf Möller authored
Update the "randomness" section for the upcoming 0.9.5a release.
-
Richard Levitte authored
-
Richard Levitte authored
Don't force the use of GNU make with Borland C++ Builder. Contributed by Joon Radley <jradley@vps.co.za>
-
- Mar 27, 2000
-
-
Bodo Möller authored
0.9.5a should not break anything that works in 0.9.5.
-