as a default for DH, so this function is no longer recommended.
DH_get_default_method() returns a pointer to the current default DH_METHOD.
-However, the meaningfulness of this result is dependant on whether the ENGINE
+However, the meaningfulness of this result is dependent on whether the ENGINE
API is being used, so this function is no longer recommended.
DH_set_method() selects B<meth> to perform all operations using the key B<dh>.
been set as a default for DSA, so this function is no longer recommended.
DSA_get_default_method() returns a pointer to the current default
-DSA_METHOD. However, the meaningfulness of this result is dependant on
+DSA_METHOD. However, the meaningfulness of this result is dependent on
whether the ENGINE API is being used, so this function is no longer
recommended.
is no longer recommended.
RAND_get_default_method() returns a pointer to the current RAND_METHOD.
-However, the meaningfulness of this result is dependant on whether the ENGINE
+However, the meaningfulness of this result is dependent on whether the ENGINE
API is being used, so this function is no longer recommended.
=head1 THE RAND_METHOD STRUCTURE
been set as a default for RSA, so this function is no longer recommended.
RSA_get_default_method() returns a pointer to the current default
-RSA_METHOD. However, the meaningfulness of this result is dependant on
+RSA_METHOD. However, the meaningfulness of this result is dependent on
whether the ENGINE API is being used, so this function is no longer
recommended.
treated as handles - ie. not only as pointers, but also as references to
the underlying ENGINE object. Ie. one should obtain a new reference when
making copies of an ENGINE pointer if the copies will be used (and
-released) independantly.
+released) independently.
ENGINE objects have two levels of reference-counting to match the way in
which the objects are used. At the most basic level, each ENGINE pointer is
specialised form of structural reference, because each functional reference
implicitly contains a structural reference as well - however to avoid
difficult-to-find programming bugs, it is recommended to treat the two
-kinds of reference independantly. If you have a functional reference to an
+kinds of reference independently. If you have a functional reference to an
ENGINE, you have a guarantee that the ENGINE has been initialised ready to
perform cryptographic operations and will remain uninitialised
until after you have released your reference.
The ENGINE API and internal architecture is currently being reviewed. Slated for
possible release in 0.9.8 is support for transparent loading of "dynamic"
ENGINEs (built as self-contained shared-libraries). This would allow ENGINE
-implementations to be provided independantly of OpenSSL libraries and/or
+implementations to be provided independently of OpenSSL libraries and/or
OpenSSL-based applications, and would also remove any requirement for
applications to explicitly use the "dynamic" ENGINE to bind to shared-library
implementations.