Skip to content
  1. Jun 09, 2000
  2. Jun 08, 2000
  3. Jun 07, 2000
  4. Jun 06, 2000
  5. Jun 05, 2000
  6. Jun 04, 2000
  7. Jun 03, 2000
  8. Jun 01, 2000
    • Richard Levitte's avatar
      There have been a number of complaints from a number of sources that names · 26a3a48d
      Richard Levitte authored
      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
    • Ulf Möller's avatar
      Use NO_FP_API. · de42b6a7
      Ulf Möller authored
      de42b6a7
    • Ulf Möller's avatar
    • Richard Levitte's avatar
    • Ulf Möller's avatar
      Bug fix for 64 bit HP-UX. · db82b8f9
      Ulf Möller authored
      Submitted by: Karsten Spang <ks@bellesystems.com>
      db82b8f9
    • Richard Levitte's avatar
      Small fix to enable reading from stdin as well. · a9ef75c5
      Richard Levitte authored
      Contributed by Yoichiro Okabe <okabe@wizsoft.co.jp>
      a9ef75c5
    • Geoff Thorpe's avatar
      "make update" + stripping the type-specific stack functions out of · 7edd2091
      Geoff Thorpe authored
      libeay.num and ssleay.num.
      7edd2091
    • Geoff Thorpe's avatar
      This change will cause builds (by default) to not use different STACK · e41c8d6a
      Geoff Thorpe authored
      structures and functions for each stack type. The previous behaviour
      can be enabled by configuring with the "-DDEBUG_SAFESTACK" option.
      This will also cause "make update" (mkdef.pl in particular) to
      update the libeay.num and ssleay.num symbol tables with the number of
      extra functions DEBUG_SAFESTACK creates.
      
      The way this change works is to accompany each DECLARE_STACK_OF()
      macro with a set of "#define"d versions of the sk_##type##_***
      functions that ensures all the existing "type-safe" stack calls are
      precompiled into the underlying stack calls. The presence or abscence
      of the DEBUG_SAFESTACK symbol controls whether this block of
      "#define"s or the DECLARE_STACK_OF() macro is taking effect. The
      block of "#define"s is in turn generated and maintained by a perl
      script (util/mkstack.pl) that encompasses the block with delimiting
      C comments. This works in a similar way to the auto-generated error
      codes and, like the other such maintenance utilities, is invoked
      by the "make update" target.
      
      A long (but mundane) commit will follow this with the results of
      "make update" - this will include all the "#define" blocks for
      each DECLARE_STACK_OF() statement, along with stripped down
      libeay.num and ssleay.num files.
      e41c8d6a
    • Geoff Thorpe's avatar
      The previous commit to crypto/stack/*.[ch] pulled the type-safety strings · ccd86b68
      Geoff Thorpe authored
      yet tighter, and also put some heat on the rest of the library by
      insisting (correctly) that compare callbacks used in stacks are prototyped
      with "const" parameters. This has led to a depth-first explosion of
      compiler warnings in the code where 1 constification has led to 3 or 4
      more. Fortunately these have all been resolved to completion and the code
      seems cleaner as a result - in particular many of the _cmp() functions
      should have been prototyped with "const"s, and now are. There was one
      little problem however;
      
      X509_cmp() should by rights compare "const X509 *" pointers, and it is now
      declared as such. However, it's internal workings can involve
      recalculating hash values and extensions if they have not already been
      setup. Someone with a more intricate understanding of the flow control of
      X509 might be able to tighten this up, but for now - this seemed the
      obvious place to stop the "depth-first" constification of the code by
      using an evil cast (they have migrated all the way here from safestack.h).
      
      Fortunately, this is the only place in the code where this was required
      to complete these type-safety changes, and it's reasonably clear and
      commented, and seemed the least unacceptable of the options. Trying to
      take the constification further ends up exploding out considerably, and
      indeed leads directly into generalised ASN functions which are not likely
      to cooperate well with this.
      ccd86b68
    • Geoff Thorpe's avatar
      This is the first of two commits (didn't want to dump them all into the · 7bb70435
      Geoff Thorpe authored
      same one). However, the first will temporarily break things until the
      second comes through. :-)
      
      The safestack.h handling was mapping compare callbacks that externally
      are of the type (int (*)(type **,type **)) into the underlying callback
      type used by stack.[ch], which is (int (*)(void *,void *)). After some
      degree of digging, it appears that the callback type in the underlying
      stack code should use double pointers too - when the compare operations
      are invoked (from sk_find and sk_sort), they are being used by bsearch
      and qsort to compare two pointers to pointers. This change corrects the
      prototyping (by only casting to the (void*,void*) form at the moment
      it is needed by bsearch and qsort) and makes the mapping in safestack.h
      more transparent. It also changes from "void*" to "char*" to stay in
      keeping with stack.[ch]'s assumed base type of "char".
      
      Also - the "const" situation was that safestack.h was throwing away
      "const"s, and to compound the problem - a close examination of stack.c
      showed that (const char **) is not really achieving what it is supposed
      to when the callback is being invoked, what is needed is
      (const char * const *). So the underlying stack.[ch] and the mapping
      macros in safestack.h have all been altered to correct this.
      
      What will follow are the vast quantities of "const" corrections required
      in stack-dependant code that was being let "slip" through when
      safestack.h was discarding "const"s. These now all come up as compiler
      warnings.
      7bb70435
    • Ulf Möller's avatar
      is needed. · f3e9b338
      Ulf Möller authored
      f3e9b338
  9. May 31, 2000