OpenSSL 1.1.0 introduced the function EVP_PKEY_up_ref which exposes the internal reference counting to user applications. The new type evp_pkey_handle takes advantage of this by providing RAII semantics for EVP_PKEY pointers similar to shared_ptr, but without having to allocate an additional control block.
One thing I am not sure about is the constructors/assignment of evp_pkey_handle. Technically EVP_PKEY_up_ref can return an error, however the only case where this might actually happen is on a plattform without atomics (pretty rare) and the mutex lock operation failed (you're probably screwed anyway if that happens), so I am tempted to replace the throw with std::terminate (or ignore the return value alltogether) and mark them as noexcept. What makes this even more of an option is the fact that EVP_PKEY_free technically has the same issue and ignores the return as well. What do you think about that @prince-chrismc ?
OpenSSL 1.1.0 introduced the function
EVP_PKEY_up_refwhich exposes the internal reference counting to user applications. The new typeevp_pkey_handletakes advantage of this by providing RAII semantics for EVP_PKEY pointers similar to shared_ptr, but without having to allocate an additional control block.One thing I am not sure about is the constructors/assignment of
evp_pkey_handle. Technically EVP_PKEY_up_ref can return an error, however the only case where this might actually happen is on a plattform without atomics (pretty rare) and the mutex lock operation failed (you're probably screwed anyway if that happens), so I am tempted to replace the throw with std::terminate (or ignore the return value alltogether) and mark them as noexcept. What makes this even more of an option is the fact that EVP_PKEY_free technically has the same issue and ignores the return as well. What do you think about that @prince-chrismc ?