PR: 308

Correct misspelled VXWORKS macros.
Add VXWORKS identifying macros to e_os2.h.
Add required inclusions and mappings for VxWorks in e_os.h.
A few small modifications to make OpenSSL build and work on VxWorks.
PR: 253, except for the  change that was handled in an earlier
         commit, and a request for easy build of just parts of OpenSSL.

Changes marked "(CHATS)" were sponsored by the Defense Advanced
Research Projects Agency (DARPA) and Air Force Research Laboratory,
Air Force Materiel Command, USAF, under agreement number
F30602-01-2-0537.

    ERR_peek_last_error
    ERR_peek_last_error_line
    ERR_peek_last_error_line_data
(supersedes ERR_peek_top_error).

Rename OPENSSL_NO_OLD_DES_SUPPORT into OPENSSL_DISABLE_OLD_DES_SUPPORT
because OPENSSL_NO_... indicates disabled algorithms (according to
mkdef.pl).

missed any.

This compiles and runs on Linux, and external applications have no
problems with it.  The definite test will be to build this on VMS.

"doall" functions to using type-safe wrappers. As and where required, this
can be replaced by redeclaring the underlying callbacks to use the
underlying "void"-based prototypes (eg. if performance suffers from an
extra level of function invocation).

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.

pointers at the end of the structure.

by providing a function pointer that is given a name instead of a BIO.
For example, this could be used to load configuration data from an
LDAP server.

'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.

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.

eliminate some of the -Wcast-qual warnings (debug-ben-strict target)

works on Unix and MS-DOS/Windows.  It does not under VMS, so open it
as text.

Update docs, change 'ca' to use the new callback parameter. Now moved key_callback
into app.c because some other utilities will use it soon.

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.

file from a bio or fp. Added some more constification to the BN library.

Submitted by: Richard Levitte <richard@levitte.org>

Submitted by:
Reviewed by:
PR:

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: ----------------------------------------------------------------------