Prevent direct instantiation of com_safearray_proxy #10278
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
com_safearray_proxy
class is meant for internal usage, but so far it was possible to instantiate it from userland, although that made no sense. However, a while ago there was a relevant change[1], namely that itsdefault_object_handlers
are now assigned when the class is registered, while previously they only have been assigned when an instance had been created internally. So now when freeing a manually created object,free_obj()
is called, although the object never has been properly initialized (causing segfaults).We fix this by introducing a
create_object()
handler which properly initializes the object with dummy values. Since a manually createdcom_safearray_proxy
still does not make sense, we disallow its instantiation.[1] 94ee4f9