=head1 DESCRIPTION
-In the description here, I<TYPE> is used a placeholder
+In the description here, B<I<TYPE>> is used a placeholder
for any of the OpenSSL datatypes, such as I<X509_CRL>.
The function parameters I<ppin> and I<ppout> are generally
either both named I<pp> in the headers, or I<in> and I<out>.
within, the DER is a serialized encoding, suitable for sending over the
network, writing to a file, and so on.
-d2i_TYPE() attempts to decode B<len> bytes at B<*ppin>. If successful a
-pointer to the B<TYPE> structure is returned and B<*ppin> is incremented to
-the byte following the parsed data. If B<a> is not B<NULL> then a pointer
-to the returned structure is also written to B<*a>. If an error occurred
-then B<NULL> is returned.
+B<d2i_I<TYPE>>() attempts to decode I<len> bytes at I<*ppin>. If successful a
+pointer to the B<I<TYPE>> structure is returned and I<*ppin> is incremented to
+the byte following the parsed data. If I<a> is not NULL then a pointer
+to the returned structure is also written to I<*a>. If an error occurred
+then NULL is returned.
-On a successful return, if B<*a> is not B<NULL> then it is assumed that B<*a>
-contains a valid B<TYPE> structure and an attempt is made to reuse it. This
+On a successful return, if I<*a> is not NULL then it is assumed that I<*a>
+contains a valid B<I<TYPE>> structure and an attempt is made to reuse it. This
"reuse" capability is present for historical compatibility but its use is
B<strongly discouraged> (see BUGS below, and the discussion in the RETURN
VALUES section).
-d2i_TYPE_bio() is similar to d2i_TYPE() except it attempts
-to parse data from BIO B<bp>.
+B<d2i_I<TYPE>_bio>() is similar to B<d2i_I<TYPE>>() except it attempts
+to parse data from BIO I<bp>.
-d2i_TYPE_fp() is similar to d2i_TYPE() except it attempts
-to parse data from FILE pointer B<fp>.
+B<d2i_I<TYPE>_fp>() is similar to B<d2i_I<TYPE>>() except it attempts
+to parse data from FILE pointer I<fp>.
-
i2d_TYPE() encodes the structure pointed to by B<a> into DER format.
-If B<ppout> is not B<NULL>, it writes the DER encoded data to the buffer
-at B<*ppout>, and increments it to point after the data just written.
+
B<i2d_I<TYPE>>() encodes the structure pointed to by I<a> into DER format.
+If I<ppout> is not NULL, it writes the DER encoded data to the buffer
+at I<*ppout>, and increments it to point after the data just written.
If the return value is negative an error occurred, otherwise it
returns the length of the encoded data.
-If B<*ppout> is B<NULL> memory will be allocated for a buffer and the encoded
-data written to it. In this case B<*ppout> is not incremented and it points
+If I<*ppout> is NULL memory will be allocated for a buffer and the encoded
+data written to it. In this case I<*ppout> is not incremented and it points
to the start of the data just written.
-i2d_TYPE_bio() is similar to i2d_TYPE() except it writes
-the encoding of the structure B<a> to BIO B<bp> and it
+B<i2d_I<TYPE>_bio>() is similar to B<i2d_I<TYPE>>() except it writes
+the encoding of the structure I<a> to BIO I<bp> and it
returns 1 for success and 0 for failure.
-i2d_TYPE_fp() is similar to i2d_TYPE() except it writes
-the encoding of the structure B<a> to BIO B<bp> and it
+B<i2d_I<TYPE>_fp>() is similar to B<i2d_I<TYPE>>() except it writes
+the encoding of the structure I<a> to BIO I<bp> and it
returns 1 for success and 0 for failure.
These routines do not encrypt private keys and therefore offer no
=head1 NOTES
-The letters B<i> and B<d> in B<i2d_TYPE> stand for
+The letters B<i> and B<d> in B<i2d_I<TYPE>>() stand for
"internal" (that is, an internal C structure) and "DER" respectively.
-So B<i2d_TYPE> converts from internal to DER.
+So B<i2d_I<TYPE>>() converts from internal to DER.
The functions can also understand B<BER> forms.
-The actual TYPE structure passed to i2d_TYPE() must be a valid
-populated B<TYPE> structure -- it B<cannot> simply be fed with an
+The actual TYPE structure passed to B<i2d_I<TYPE>>() must be a valid
+populated B<I<TYPE>> structure -- it B<cannot> simply be fed with an
empty structure such as that returned by TYPE_new().
The encoded data is in binary form and may contain embedded zeroes.
Functions such as strlen() will B<not> return the correct length
of the encoded structure.
-The ways that B<*ppin> and B<*ppout> are incremented after the operation
+The ways that I<*ppin> and I<*ppout> are incremented after the operation
can trap the unwary. See the B<WARNINGS> section for some common
errors.
The reason for this-auto increment behaviour is to reflect a typical
Represents a DSA public key using a B<SubjectPublicKeyInfo> structure.
-=item B<DSAPublicKey, DSAPrivateKey>
+=item B<DSAPublicKey>, B<DSAPrivateKey>
Use a non-standard OpenSSL format and should be avoided; use B<DSA_PUBKEY>,
-
B<PEM_write_PrivateKey(3)>, or similar instead.
+
L<PEM_write_PrivateKey(3)>, or similar instead.
=item B<ECDSA_SIG>
=head1 RETURN VALUES
-d2i_TYPE(), d2i_TYPE_bio() and d2i_TYPE_fp() return a valid B<TYPE> structure
-or B<NULL> if an error occurs. If the "reuse" capability has been used with
-a valid structure being passed in via B<a>, then the object is freed in
-the event of error and B<*a> is set to NULL.
+B<d2i_I<TYPE>>(), B<d2i_I<TYPE>_bio>() and B<d2i_I<TYPE>_fp>() return a valid
+B<I<TYPE>> structure or NULL if an error occurs. If the "reuse" capability has
+been used with a valid structure being passed in via I<a>, then the object is
+freed in the event of error and I<*a> is set to NULL.
-i2d_TYPE() returns the number of bytes successfully encoded or a negative
+B<i2d_I<TYPE>>() returns the number of bytes successfully encoded or a negative
value if an error occurs.
-i2d_TYPE_bio() and i2d_TYPE_fp() return 1 for success and 0 if an error
-occurs.
+B<i2d_I<TYPE>_bio>() and B<i2d_I<TYPE>_fp>() return 1 for success and 0 if an
+error occurs.
=head1 EXAMPLES
...
OPENSSL_free(buf);
-This code will result in B<buf> apparently containing garbage because
+This code will result in I<buf> apparently containing garbage because
it was incremented after the call to point after the data just written.
-Also B<buf> will no longer contain the pointer allocated by OPENSSL_malloc()
+Also I<buf> will no longer contain the pointer allocated by OPENSSL_malloc()
and the subsequent call to OPENSSL_free() is likely to crash.
-Another trap to avoid is misuse of the B<a> argument to d2i_TYPE():
+Another trap to avoid is misuse of the I<a> argument to B<d2i_I<TYPE>>():
X509 *x;
/* error */
This will probably crash somewhere in d2i_X509(). The reason for this
-is that the variable B<x> is uninitialized and an attempt will be made to
+is that the variable I<x> is uninitialized and an attempt will be made to
interpret its (invalid) value as an B<X509> structure, typically causing
-a segmentation violation. If B<x> is set to NULL first then this will not
+a segmentation violation. If I<x> is set to NULL first then this will not
happen.
=head1 BUGS
-In some versions of OpenSSL the "reuse" behaviour of d2i_TYPE() when
-B<*a> is valid is broken and some parts of the reused structure may
+In some versions of OpenSSL the "reuse" behaviour of B<d2i_I<TYPE>>() when
+I<*a> is valid is broken and some parts of the reused structure may
persist if they are not present in the new one. Additionally, in versions of
OpenSSL prior to 1.1.0, when the "reuse" behaviour is used and an error occurs
the behaviour is inconsistent. Some functions behaved as described here, while
-some did not free B<*a> on error and did not set B<*a> to NULL.
+some did not free I<*a> on error and did not set I<*a> to NULL.
As a result of the above issues the "reuse" behaviour is strongly discouraged.
-i2d_TYPE() will not return an error in many versions of OpenSSL,
+B<i2d_I<TYPE>>() will not return an error in many versions of OpenSSL,
if mandatory fields are not initialized due to a programming error
then the encoded structure may contain invalid data or omit the
-fields entirely and will not be parsed by d2i_TYPE(). This may be
-fixed in future so code should not assume that i2d_TYPE() will
+fields entirely and will not be parsed by B<d2i_I<TYPE>>(). This may be
+fixed in future so code should not assume that B<i2d_I<TYPE>>() will
always succeed.
-Any function which encodes a structure (i2d_TYPE(),
-i2d_TYPE() or i2d_TYPE()) may return a stale encoding if the
+Any function which encodes a structure (B<i2d_I<TYPE>>(),
+B<i2d_I<TYPE>>() or B<i2d_I<TYPE>>()) may return a stale encoding if the
structure has been modified after deserialization or previous
serialization. This is because some objects cache the encoding for
efficiency reasons.
projects / openssl.git / blobdiff