This is the first of two commits (didn't want to dump them all into the
authorGeoff Thorpe <geoff@openssl.org>
Thu, 1 Jun 2000 02:15:40 +0000 (02:15 +0000)
committerGeoff Thorpe <geoff@openssl.org>
Thu, 1 Jun 2000 02:15:40 +0000 (02:15 +0000)
commit7bb7043580900b8f06cb418b46004b755ff0fc96
tree2c7daae78031c2b18e2ecd27473b57f8a3bef121
parentf3e9b338e0badedc87f6014bdbb8594e5af00acd
This is the first of two commits (didn't want to dump them all into the
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.
crypto/stack/safestack.h
crypto/stack/stack.c
crypto/stack/stack.h