At one point in the SSLeay days, all the ASN1_STRING typedefs were
separate structs (but only in debug builds) and the M_ASN1_* macros
included type casts to handle this.
This is long gone, but we still have the M_ASN1_* macros. Remove the
casts and switch code within the library to call the macros. Some
subtleties:
- The "MSTRING" types (what OpenSSL calls its built-in CHOICEs
containing some set of string types) are weird because the M_FOO_new()
macro and the tasn_new.c FOO_new() function behave differently. I've
split those into a separate CL.
- ASN1_STRING_type, etc., call into the macro, which accesses the field
directly. This CL inverts the dependency.
- ASN1_INTEGER_new and ASN1_INTEGER_free, etc., are generated via
IMPLEMENT_ASN1_STRING_FUNCTIONS in tasn_typ.c. I've pointed
M_ASN1_INTEGER_new and M_ASN1_INTEGER_free to these fields. (The free
function is a no-op, but consistent.)
- The other macros like M_ASN1_BIT_STRING_dup largely do not have
corresponding functions. I've aligned with OpenSSL in just using the
generic ASN1_STRING_dup function. But some others, like
M_ASN1_OCTET_STRING_dup have a corresponding ASN1_OCTET_STRING_dup
function. OpenSSL retained these, so I have too.
Update-Note: Some external code uses the M_ASN1_* macros. This should
remain compatible, but some type errors may have gotten through
unnoticed. This CL restores type-checking.
Change-Id: I8656abc7d0f179192e05a852c97483c021ad9b20
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44045
Reviewed-by: Adam Langley <agl@google.com>
See 309e73dfe067b3b774ef6f57bf665f41373a81ca from upstream, though note
that v3_alt.c's fix was rewritten. (We don't have sk_reserve, and I
don't think their fix was quite right anyway.)
Change-Id: Ieabd19d87d4628658324b212cce2ed3ce451ad22
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43284
Reviewed-by: Adam Langley <agl@google.com>
David Benjamin
Adam Langley