1. 09 11月, 2000 1 次提交
  2. 27 10月, 2000 2 次提交
  3. 15 10月, 2000 1 次提交
  4. 25 9月, 2000 1 次提交
  5. 07 9月, 2000 1 次提交
  6. 28 8月, 2000 1 次提交
  7. 14 8月, 2000 1 次提交
  8. 26 7月, 2000 2 次提交
  9. 21 7月, 2000 1 次提交
  10. 05 7月, 2000 1 次提交
    • R
      I got sick and tired of having to keep track of NIDs when such a thing · c2bbf9cf
      Richard Levitte 提交于
      could be done automagically, much like the numbering in libeay.num and
      ssleay.num.  The solution works as follows:
      
        - New object identifiers are inserted in objects.txt, following the
          syntax given in objects.README.
        - objects.pl is used to process obj_mac.num and create a new
          obj_mac.h.
        - obj_dat.pl is used to create a new obj_dat.h, using the data in
          obj_mac.h.
      
      This is currently kind of a hack, and the perl code in objects.pl
      isn't very elegant, but it works as I intended.  The simplest way to
      check that it worked correctly is to look in obj_dat.h and check the
      array nid_objs and make sure the objects haven't moved around (this is
      important!).  Additions are OK, as well as consistent name changes.
      c2bbf9cf
  11. 09 6月, 2000 1 次提交
    • R
      Using checks of the existence of HEADER_{foo}_H in other header files · ef33b970
      Richard Levitte 提交于
      was a really bad idea.  For example, the following:
      
      	#include <x509.h>
      	#include <bio.h>
      	#include <asn1.h>
      
      would make sure that things like ASN1_UTCTIME_print() wasn't defined
      unless you moved the inclusion of bio.h to above the inclusion of
      x509.h.  The reason is that x509.h includes asn1.h, and the
      declaration of ASN1_UTCTIME_print() depended on the definition of
      HEADER_BIO_H.  That's what I call an obscure bug.
      
      Instead, this change makes sure that whatever header files are needed
      for the correct process of one header file are included automagically,
      and that the definitions of, for example, BIO-related things are
      dependent on the absence of the NO_{foo} macros.  This is also
      consistent with the way parts of OpenSSL can be excluded at will.
      ef33b970
  12. 04 6月, 2000 1 次提交
  13. 02 6月, 2000 1 次提交
    • R
      There have been a number of complaints from a number of sources that names · 26a3a48d
      Richard Levitte 提交于
      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.
      26a3a48d
  14. 24 5月, 2000 1 次提交
  15. 02 5月, 2000 2 次提交
  16. 30 4月, 2000 1 次提交
  17. 15 4月, 2000 1 次提交
  18. 09 4月, 2000 1 次提交
  19. 05 4月, 2000 1 次提交
    • G
      This commit ties the new DSO code (crypto/dso/) into the build for a · 9ec0126e
      Geoff Thorpe 提交于
      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:
      9ec0126e
  20. 04 3月, 2000 1 次提交
  21. 25 2月, 2000 1 次提交
  22. 06 2月, 2000 1 次提交
  23. 04 2月, 2000 1 次提交
  24. 31 1月, 2000 1 次提交
  25. 24 1月, 2000 1 次提交
    • D
      · dd9d233e
      Dr. Stephen Henson 提交于
      Tidy up CRYPTO_EX_DATA structures.
      dd9d233e
  26. 15 1月, 2000 1 次提交
  27. 14 1月, 2000 1 次提交
  28. 30 7月, 1999 1 次提交
  29. 13 7月, 1999 1 次提交
  30. 08 6月, 1999 1 次提交
  31. 05 6月, 1999 1 次提交
  32. 21 5月, 1999 3 次提交
    • B
      It was a very bad idea to use #include "../e_os.h" -- when this occurs · 7e701817
      Bodo Möller 提交于
      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.
      7e701817
    • B
      Add a kludge :-( · d6847aed
      Bodo Möller 提交于
      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.
      d6847aed
    • B
      Don't install e_os.h in include/openssl, use it only as a local · 17e3dd1c
      Bodo Möller 提交于
      include file.
      17e3dd1c
  33. 15 5月, 1999 1 次提交
  34. 14 5月, 1999 1 次提交
  35. 05 5月, 1999 1 次提交