Thanks to Dr Stephen Henson <shenson@drh-consultancy.co.uk> for making
me aware of this error.

around them.

NOTE: because two new locks are added, this adds potential binary
incompatibility with earlier versions in the 0.9.7 series.  However,
those locks will only ever be touched when FIPS_mode_set() is called
and after, thanks to a variable that's only changed from 0 to 1 once
(when FIPS_mode_set() is called).  So basically, as long as FIPS mode
hasn't been engaged explicitely by the calling application, the new
locks are treated as if they didn't exist at all, thus not becoming a
problem.  Applications that are built or rebuilt to use FIPS
functionality will need to be recompiled in any case, thus not being a
problem either.

the fips subdirectory, not the crypto one...

name is defined.

Go up one directory level before dealing with FIPS stuff.

cipher suite is FIPS compatible.

New cipherstring "FIPS" is all FIPS compatible ciphersuites except eNULL.

Only allow FIPS ciphersuites in FIPS mode.

static variable

will either be optimized away or never performed. The trouble is that
compiler first parses code, then optimizes, not both at once...

avoid use of prohibited MD5 algorithm.

instead of local time.

we were mislead by _MSC_VER macro, which is defined by *all* Windows
Microsoft compilers.

compilers, e.g. DEC C.

_stricmp() on that platform, use the appropriate header file for it,
<string.h>.
o_str.h: we only want to get size_t, which is defined in <stddef.h>.

Philippe Bougeret <philippe.bougeret@freesbee.fr> notified us about Windows
not having a <strings.h>

Add a note as to how these functions do not always return the key size, and
how one can deal with that.

PR: 907

PR: 499

there's no need for a larger BUFSIZE any more...

PR: 904

PR: 904