functions need to be constified, and therefore meant a number of easy
changes a little everywhere.
Now, if someone could explain to me why OBJ_dup() cheats...
DECLARE/IMPLEMENT macros now exist to create type (and prototype) safe
wrapper functions that avoid the use of function pointer casting yet retain
type-safety for type-specific callbacks. However, most of the usage within
OpenSSL itself doesn't really require the extra function because the hash
and compare callbacks are internal functions declared only for use by the
hash table. So this change catches all those cases and reimplements the
functions using the base-level LHASH prototypes and does per-variable
casting inside those functions to convert to the appropriate item type.
The exception so far is in ssl_lib.c where the hash and compare callbacks
are not static - they're exposed in ssl.h so their prototypes should not be
changed. In this last case, the IMPLEMENT_LHASH_*** macros have been left
intact.
casts) used in the lhash code are about as horrible and evil as they can
be. For starters, the callback prototypes contain empty parameter lists.
Yuck.
This first change defines clearer prototypes - including "typedef"'d
function pointer types to use as "hash" and "compare" callbacks, as well as
the callbacks passed to the lh_doall and lh_doall_arg iteration functions.
Now at least more explicit (and clear) casting is required in all of the
dependant code - and that should be included in this commit.
The next step will be to hunt down and obliterate some of the function
pointer casting being used when it's not necessary - a particularly evil
variant exists in the implementation of lh_doall.
NCONF_get_number_e() is defined (_e for "error checking") and is
promoted strongly. The old NCONF_get_number is kept around for
binary backward compatibility.
Actually, it's a feature that it goes looking at environment
variables. It's just a pity that it's at the cost of the error
checking... I'll see if I can come up with a better interface for
this.
After some messing around this seems to work but needs
a few more tests. Working out the syntax for sk_set_cmp_func()
(cast it to a function that itself returns a function pointer)
was painful :-(
Needs some testing to see what other compilers think of this
syntax.
Also needs similar stuff for ASN1_SET_OF etc etc.
'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'...
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.
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.
"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.
the result.
I have retained the old behavior of the CONF_* functions, and have
added a more "object oriented" interface through NCONF_* functions
(New CONF, you see :-)), working the same way as, for example, the
BIO interface. Really, the CONF_* are rewritten so they use the
NCONF_* functions internally.
In addition to that, I've split the old conf.c code into two files,
conf_def.c and conf_api.c. conf_def.c contains the default config
object that reads a configuration file the standard OpenSSL way, as
well as configuration file with Win32 registry file syntax (I'm not
sure I got that one right). conf_api.c provides an API to build other
configuration file readers around (can you see a configuraion file in
XML? I can :-)).
Finally, I've changed the name conf_lcl.h to conf_def.h, since it's
made specifically for that "class" and none others.
seemed like a good idea at the time... several hours later it was rather
obvious that these are used all over the place making the changes rather
extensive.
in cryptlib.h (which is often included as "../cryptlib.h"), then the
question remains relative to which directory this is to be interpreted.
gcc went one further directory up, as intended; but makedepend thinks
differently, and so probably do some C compilers. So the ../ must go away;
thus e_os.h goes back into include/openssl (but I now use
#include "openssl/e_os.h" instead of <openssl/e_os.h> to make the point) --
and we have another huge bunch of dependency changes. Argh.
There were problems with putting e_os.h just into the top directory,
because the test programs are compiled within test/ in the "standard"
case in in their original directories in the makefile.one case;
and in the latter symlinks may not be available.
to error code script: it can now find untranslatable function codes (usually
because the function is static and not defined in a header: occasionally because
of a typo...) and unreferenced function and reason codes. To see this try:
perl util/mkerr.pl -recurse -debug
Also fixed some typos in crypto/pkcs12 that this found :-)
Also tidy up some error calls that had to be all on one line: the old error
script couldn't find codes unless the call was all on one line.
script, translates function codes better and doesn't need the K&R function
prototypes to work (NB. the K&R prototypes can't be wiped just yet: they are
still needed by the DEF generator...). I also ran the script with the -rewrite
option to update all the header and source files.
consistent in the source tree and replaced `/bin/rm' by `rm'. Additonally
cleaned up the `make links' target: Remove unnecessary semicolons, subsequent
redundant removes, inline point.sh into mklink.sh to speed processing and no
longer clutter the display with confusing stuff. Instead only the actually
done links are displayed.
1. The already released version was 0.9.1c and not 0.9.1b
2. The next release should be 0.9.2 and not 0.9.1d, because
first the changes are already too large, second we should avoid any more
0.9.1x confusions and third, the Apache version semantics of
VERSION.REVISION.PATCHLEVEL for the version string is reasonable (and here
.2 is already just a patchlevel and not major change).
tVS: ----------------------------------------------------------------------
