Skip to content

Allocate OpenSSL objects in #initialize{,_copy}#1046

Open
rhenium wants to merge 10 commits intoruby:masterfrom
rhenium:ky/alloc-in-initialize
Open

Allocate OpenSSL objects in #initialize{,_copy}#1046
rhenium wants to merge 10 commits intoruby:masterfrom
rhenium:ky/alloc-in-initialize

Conversation

@rhenium
Copy link
Copy Markdown
Member

@rhenium rhenium commented Apr 29, 2026

Allocate the underlying OpenSSL object in #initialize{,_copy} instead of .allocate. Allocating an empty OpenSSL object in .allocate is wasteful because #initialize{,_copy} cannot always reuse an existing object and have to allocate a new one.

Some ruby/openssl classes already follow this approach, such as OpenSSL::PKey::PKey. Let's standardize on it.

Also expand New*() and Set*() macros, which are not very helpful for readability in my opinion.

rhenium added 10 commits April 30, 2026 01:41
The man page discourages the use of this behavior. This also fixes a
potential memory leak reported at
<ruby#1011>.
Also, avoid using the "reuse" behavior of d2i_*{,_bio}() functions.
Allocate the underlying OpenSSL object in #initialize{,_copy} instead
of .allocate. Allocating an empty OpenSSL object in .allocate is
wasteful because #initialize{,_copy} cannot always reuse an existing
object and have to allocate a new one.

Some ruby/openssl classes already follow this approach, such as
OpenSSL::PKey::PKey. Let's standardize on it.

Also expand New*() and Set*() macros, which are not very helpful for
readability in my opinion.
Allocate the wrapper object before trying to load a provider.

Also, expand NewProvider() and SetProvider() macros.
@rhenium rhenium force-pushed the ky/alloc-in-initialize branch from 890a3f9 to 1c7f29a Compare April 29, 2026 16:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant