=head1 NOTES
-On Windows platforms the openssl/async.h header is dependent on some
-of the types customarily made available by including windows.h. The
+On Windows platforms the F<< <openssl/async.h> >> header is dependent on some
+of the types customarily made available by including F<< <windows.h> >>. The
application developer is likely to require control over when the latter
is included, commonly as one of the first included headers. Therefore,
it is defined as an application developer's responsibility to include
-windows.h prior to async.h.
+F<< <windows.h> >> prior to F<< <openssl/async.h> >>.
=head1 SEE ALSO
=head1 NOTES
-On Windows platforms the openssl/async.h header is dependent on some
-of the types customarily made available by including windows.h. The
+On Windows platforms the F<< <openssl/async.h> >> header is dependent on some
+of the types customarily made available by including F<< <windows.h> >>. The
application developer is likely to require control over when the latter
is included, commonly as one of the first included headers. Therefore,
it is defined as an application developer's responsibility to include
-windows.h prior to async.h.
+F<< <windows.h> >> prior to F<< <openssl/async.h> >>.
=head1 EXAMPLES
The following general types are defined:
B<BIO_TYPE_DESCRIPTOR>, B<BIO_TYPE_FILTER>, and B<BIO_TYPE_SOURCE_SINK>.
-For a list of the specific types, see the B<openssl/bio.h> header file.
+For a list of the specific types, see the F<< <openssl/bio.h> >> header file.
BIO_next() returns the next BIO in a chain. It can be used to traverse all BIOs
in a chain or used in conjunction with BIO_find_type() to find all BIOs of a
Use BIO_get_new_index() to get the value for B<type>.
The set of
-standard OpenSSL provided BIO types is provided in B<bio.h>. Some examples
-include B<BIO_TYPE_BUFFER> and B<BIO_TYPE_CIPHER>. Filter BIOs should have a
-type which have the "filter" bit set (B<BIO_TYPE_FILTER>). Source/sink BIOs
-should have the "source/sink" bit set (B<BIO_TYPE_SOURCE_SINK>). File descriptor
-based BIOs (e.g. socket, fd, connect, accept etc) should additionally have the
-"descriptor" bit set (B<BIO_TYPE_DESCRIPTOR>). See the L<BIO_find_type(3)> page for
-more information.
+standard OpenSSL provided BIO types is provided in F<< <openssl/bio.h> >>.
+Some examples include B<BIO_TYPE_BUFFER> and B<BIO_TYPE_CIPHER>. Filter BIOs
+should have a type which have the "filter" bit set (B<BIO_TYPE_FILTER>).
+Source/sink BIOs should have the "source/sink" bit set (B<BIO_TYPE_SOURCE_SINK>).
+File descriptor based BIOs (e.g. socket, fd, connect, accept etc) should
+additionally have the "descriptor" bit set (B<BIO_TYPE_DESCRIPTOR>). See the
+L<BIO_find_type(3)> page for more information.
BIO_meth_free() destroys a B<BIO_METHOD> structure and frees up any memory
associated with it.
=head1 NOTES
On Windows platforms the CRYPTO_THREAD_* types and functions in the
-openssl/crypto.h header are dependent on some of the types customarily
-made available by including windows.h. The application developer is
-likely to require control over when the latter is included, commonly as
-one of the first included headers. Therefore, it is defined as an
-application developer's responsibility to include windows.h prior to
-crypto.h where use of CRYPTO_THREAD_* types and functions is required.
+F<< <openssl/crypto.h> >> header are dependent on some of the types
+customarily made available by including F<< <windows.h> >>. The application
+developer is likely to require control over when the latter is included,
+commonly as one of the first included headers. Therefore, it is defined as an
+application developer's responsibility to include F<< <windows.h> >> prior to
+F<< <openssl/crypto.h> >> where use of CRYPTO_THREAD_* types and functions is
+required.
=head1 EXAMPLES
In addition, the B<APP> name is reserved for use by application code.
-Each is identified by an B<CRYPTO_EX_INDEX_xxx> define in the B<crypto.h>
-header file. In addition, B<CRYPTO_EX_INDEX_APP> is reserved for
+Each is identified by an B<CRYPTO_EX_INDEX_xxx> define in the header file
+F<< <openssl/crypto.h> >>. In addition, B<CRYPTO_EX_INDEX_APP> is reserved for
applications to use this facility for their own structures.
The API described here is used by OpenSSL to manipulate exdata for specific
EC_GROUP_get_field_type() returns either B<NID_X9_62_prime_field> for prime curves
or B<NID_X9_62_characteristic_two_field> for binary curves;
-these values are defined in the obj_mac.h header file.
+these values are defined in the F<< <openssl/obj_mac.h> >> header file.
EC_GROUP_check_named_curve() returns the nid of the matching named curve, otherwise it returns 0 for no match, or -1 on error.
EC_GROUP_cmp() returns 0 if the curves are equal, 1 if they are not equal, or -1 on error.
-EC_GROUP_get_basis_type() returns the values NID_X9_62_tpBasis or NID_X9_62_ppBasis (as defined in <openssl/obj_mac.h>) for a
+EC_GROUP_get_basis_type() returns the values NID_X9_62_tpBasis or NID_X9_62_ppBasis (as defined in F<< <openssl/obj_mac.h> >>) for a
trinomial or pentanomial respectively. Alternatively in the event of an error a 0 is returned.
=head1 SEE ALSO
To clarify a particular function's handling of references, one should
always consult that function's documentation "man" page, or failing that
-the openssl/engine.h header file includes some hints.
+the F<< <openssl/engine.h> >> header file includes some hints.
I<Functional references>
structural reference. Note that some control commands are defined by OpenSSL
itself and it will intercept and handle these control commands on behalf of the
ENGINE, i.e. the ENGINE's ctrl() handler is not used for the control command.
-openssl/engine.h defines an index, ENGINE_CMD_BASE, that all control commands
-implemented by ENGINEs should be numbered from. Any command value lower than
-this symbol is considered a "generic" command is handled directly by the
-OpenSSL core routines.
+F<< <openssl/engine.h> >> defines an index, ENGINE_CMD_BASE, that all control
+commands implemented by ENGINEs should be numbered from. Any command value
+lower than this symbol is considered a "generic" command is handled directly
+by the OpenSSL core routines.
It is using these "core" control commands that one can discover the control
commands implemented by a given ENGINE, specifically the commands:
=head1 NOTES
The algorithms for the OWF (one-way function) and for the MAC (message
-authentication code) may be any with a NID defined in C<openssl/objects.h>.
+authentication code) may be any with a NID defined in F<< <openssl/objects.h> >>.
As specified by RFC 4210, these should include NID_hmac_sha1.
RFC 4210 recommends that the salt SHOULD be at least 8 bytes (64 bits) long,
=for openssl generic
- #include "openssl/param_build.h"
+ #include <openssl/param_build.h>
typedef struct OSSL_PARAM_BLD;
=item *
-The macro B<OPENSSL_NO_TRACE> is defined in C<openssl/opensslconf.h>.
+The macro B<OPENSSL_NO_TRACE> is defined in F<< <openssl/opensslconf.h> >>.
=item *
necessary to configure and build OpenSSL with the 'enable-trace' option.
When the library is built with tracing disabled, the macro
-B<OPENSSL_NO_TRACE> is defined in C<openssl/opensslconf.h> and all
+B<OPENSSL_NO_TRACE> is defined in F<< <openssl/opensslconf.h> >> and all
functions described here are inoperational, i.e. will do nothing.
=head1 HISTORY
The I<name> is 16 characters long and is used as a key identifier.
The I<iv> length is the length of the IV of the corresponding cipher. The
-maximum IV length is B<EVP_MAX_IV_LENGTH> bytes defined in B<evp.h>.
+maximum IV length is B<EVP_MAX_IV_LENGTH> bytes defined in F<< <openssl/evp.h> >>.
The initialization vector I<iv> should be a random value. The cipher context
I<ctx> should use the initialisation vector I<iv>. The cipher context can be
=head1 NOTES
-On Windows platforms the openssl/async.h header is dependent on some
-of the types customarily made available by including windows.h. The
+On Windows platforms the F<< <openssl/async.h> >> header is dependent on some
+of the types customarily made available by including F<< <windows.h> >>. The
application developer is likely to require control over when the latter
is included, commonly as one of the first included headers. Therefore,
it is defined as an application developer's responsibility to include
-windows.h prior to async.h.
+F<< <windows.h> >> prior to F<< <openssl/async.h> >>.
=head1 SEE ALSO
various B<X509_NAME_ENTRY> utility functions on the result.
The list of all relevant B<NID_*> and B<OBJ_* codes> can be found in
-the source code header files E<lt>openssl/obj_mac.hE<gt> and/or
-E<lt>openssl/objects.hE<gt>.
+the source code header files F<< <openssl/obj_mac.h> >> and/or
+F<< <openssl/objects.h> >>.
Applications which could pass invalid NIDs to X509_NAME_get_index_by_NID()
should check for the return value of -2. Alternatively the NID validity
=head1 BUGS
-This function uses the header F<< <x509.h> >>
+This function uses the header F<< <openssl/x509.h> >>
as opposed to most chain verification
-functions which use F<< <x509_vfy.h> >>.
+functions which use F<< <openssl/x509_vfy.h> >>.
=head1 SEE ALSO
projects / openssl.git / commitdiff