1. 27 Dec, 2003 2 commits
  2. 20 Dec, 2003 1 commit
  3. 11 Dec, 2003 1 commit
  4. 10 Dec, 2003 2 commits
  5. 03 Dec, 2003 1 commit
  6. 01 Dec, 2003 4 commits
  7. 29 Nov, 2003 2 commits
  8. 28 Nov, 2003 4 commits
  9. 27 Nov, 2003 1 commit
    • Richard Levitte's avatar
      If dynamically-loadable ENGINEs are linked against a shared-library version · 04dc4edb
      Richard Levitte authored
      of libcrypto, then it is possible that when they are loaded they will share
      the same static data as the loading application/library. This means it will
      be too late to set memory/ERR/ex_data/[etc] callbacks, but entirely
      unnecessary to try.
      
      This change (and a great part of this comment) was implemented in
      0.9.8-dev a long time ago, but slightly differently.  In 0.9.8-dev, a
      specific function that just returns a pointer to some static object is
      used. For 0.9.7x, we couldn't do that, since the way we handle feature
      freezes is, among other, to not add any more non-static functions.
      Instead, we use the function ERR_get_implementation() and compare the
      returned value with fns->err_fns, a member of fns that already is
      there, and which therefore can safely be used in this manner.
      
      What happens is that if the loaded ENGINE's return value from this
      function matches the loading application/library's return value - they
      share static data. If they don't match, the loaded ENGINE has its own
      copy of libcrypto's static data and so the callbacks need to be set.
      04dc4edb
  10. 24 Nov, 2003 1 commit
  11. 22 Nov, 2003 1 commit
  12. 20 Nov, 2003 1 commit
  13. 19 Nov, 2003 1 commit
  14. 18 Nov, 2003 1 commit
  15. 16 Nov, 2003 2 commits
  16. 10 Nov, 2003 2 commits
  17. 29 Oct, 2003 1 commit
  18. 15 Oct, 2003 1 commit
  19. 11 Oct, 2003 1 commit
  20. 10 Oct, 2003 1 commit
  21. 07 Oct, 2003 1 commit
  22. 02 Oct, 2003 2 commits
  23. 01 Oct, 2003 4 commits
  24. 30 Sep, 2003 2 commits