Andy Polyakov [Tue, 6 Jun 2000 15:21:12 +0000 (15:21 +0000)]
Compaq C warns that "the expression 'p=scan_esc(p)' modifies the variable
'p' more than once without an intervening sequence point. This behavior
is undefined." What it essentially complains about is 'p=p+=1'. Now it's
changed to 'p=p+1'...
Richard Levitte [Thu, 1 Jun 2000 22:19:21 +0000 (22:19 +0000)]
There have been a number of complaints from a number of sources that names
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.
Geoff Thorpe [Thu, 1 Jun 2000 05:13:52 +0000 (05:13 +0000)]
This change will cause builds (by default) to not use different STACK
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.
Geoff Thorpe [Thu, 1 Jun 2000 02:36:58 +0000 (02:36 +0000)]
The previous commit to crypto/stack/*.[ch] pulled the type-safety strings
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.
Geoff Thorpe [Thu, 1 Jun 2000 02:15:40 +0000 (02:15 +0000)]
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.
Geoff Thorpe [Wed, 31 May 2000 15:28:01 +0000 (15:28 +0000)]
All the little functions created by the IMPLEMENT_STACK_OF() macro will
cast their type-specific STACK into a real STACK and call the underlying
sk_*** function. The problem is that if the STACK_OF(..) parameter being
passed in has a "const *" qualifier, it is discarded by the cast.
I'm currently implementing a fix for this but in the mean-time, this is
one case I noticed (a few type-specific sk_**_num() functions pass in
const type-specific stacks). If there are other errors in the code where
consts are being discarded, we will similarly not notice them. yuck.
Declare ciphers in terms of macros. This reduces
the amount of code and places each block cipher EVP
definition in a single file instead of being spread
over 4 files.
Declare ciphers in terms of macros. This reduces
the amount of code and places each block cipher EVP
definition in a single file instead of being spread
over 4 files.
Geoff Thorpe [Mon, 29 May 2000 03:17:45 +0000 (03:17 +0000)]
This declaration seems to have been added into the header file accidently.
There's no trace of it being implemented and it doesn't seem to have been
intended given that it is prototyped with a BIO yet there was a BIO-
specific version added in at the same time.
Change functions like EVP_EncryptUpdate() so they now return a
value. These normally have software only implementations
which cannot fail so this was acceptable. However ciphers
can be implemented in hardware and these could return errors.
Richard Levitte [Thu, 18 May 2000 21:22:50 +0000 (21:22 +0000)]
Add a new file where all the standards and other documents that we try
to adhere to are listed. It should be regarded as a complement to
whatever is out on the web, including the docs in http://www.openssl.org/
Bodo Möller [Thu, 11 May 2000 23:10:27 +0000 (23:10 +0000)]
When open()ing 'file' in RAND_write_file, don't use O_EXCL.
This is superfluous now that we don't have to avoid creating
multiple versions of the file on VMS (because older versions
are now deleted).
Richard Levitte [Tue, 2 May 2000 13:36:50 +0000 (13:36 +0000)]
In Message-ID: <003201bfb332$14a07520$0801a8c0@janm.transactionsite.com>,
"Jan Mikkelsen" <janm@transactionsite.com> correctly states that the
OpenSSL header files have #include's and extern "C"'s in an incorrect
order. Thusly fixed.
Also, make the memory debugging routines defined and declared with
prototypes, and use void* instead of char* for memory blobs.
And last of all, redo the ugly callback construct for elegance and
better definition (with prototypes).
Richard Levitte [Tue, 2 May 2000 12:35:04 +0000 (12:35 +0000)]
In Message-ID: <003201bfb332$14a07520$0801a8c0@janm.transactionsite.com>,
"Jan Mikkelsen" <janm@transactionsite.com> correctly states that the
OpenSSL header files have #include's and extern "C"'s in an incorrect
order. Thusly fixed.
Richard Levitte [Tue, 2 May 2000 12:16:01 +0000 (12:16 +0000)]
In Message-ID: <003201bfb332$14a07520$0801a8c0@janm.transactionsite.com>,
"Jan Mikkelsen" <janm@transactionsite.com> correctly states that the
OpenSSL header files have #include's and extern "C"'s in an incorrect
order. Thusly fixed.