Skip to content
  1. Jun 16, 2000
    • Geoff Thorpe's avatar
      Currently the DSO_METHOD interface has one entry point to bind all · e9a68cfb
      Geoff Thorpe authored
      "symbols" including functions (of all prototypes( and variables. Whilst
      casting any function type to another violates ANSI C (I believe), it is
      a necessary evil in shared-library APIs. However, it is quite
      conceivable that functions in general and data symbols could very well
      be represented differently to each other on some systems, as Bodo said;
      
      > Since the function/object distinction is a lot more likely to be
      > important on real-life platforms supporting DSO *and* it can be quite
      > easily done *and* it will silence compilers that don't like
      > assignments from void pointers to function pointer variables, why
      > not do it?
      
      I agree. So this change splits the "dso_bind" handler in DSO_METHOD
      into "dso_bind_var" and "dso_bind_func". Similarly the exported
      function DSO_bind() has been split in two. I've also put together
      changes for the various DSO_METHOD implementations, but so far only
      DSO_dlfcn() has been tested. BTW: The prototype for dso_bind had been
      a bit strange so I've taken the opportunity to change its shape (in
      both variations).
      
      Also, the README has been updated - particularly with a note about
      using customised native name-translation for shared libraries (and that
      you can't do it yet).
      e9a68cfb
  2. Jun 15, 2000
  3. Jun 14, 2000
  4. Jun 13, 2000
  5. Jun 12, 2000
  6. Jun 11, 2000
  7. Jun 10, 2000
  8. Jun 09, 2000
    • Bodo Möller's avatar
      Comment about bcopy on SunOS 4.x. · b908bd4e
      Bodo Möller authored
      b908bd4e
    • Richard Levitte's avatar
      Using checks of the existence of HEADER_{foo}_H in other header files · ef33b970
      Richard Levitte authored
      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
    • Bodo Möller's avatar
      Comment for increased code clarity. · 814ed26c
      Bodo Möller authored
      814ed26c
  9. Jun 08, 2000
  10. Jun 07, 2000
  11. Jun 06, 2000
  12. Jun 05, 2000
  13. Jun 04, 2000
  14. Jun 03, 2000