Page MenuHomePhabricator

[native] Disable CryptoModule copy construction
ClosedPublic

Authored by ashoat on Oct 22 2023, 9:07 AM.
Tags
None
Referenced Files
F3246325: D9562.diff
Thu, Nov 14, 10:53 PM
Unknown Object (File)
Mon, Oct 28, 3:47 PM
Unknown Object (File)
Oct 10 2024, 5:25 PM
Unknown Object (File)
Oct 4 2024, 1:46 AM
Unknown Object (File)
Oct 4 2024, 1:46 AM
Unknown Object (File)
Oct 4 2024, 1:46 AM
Unknown Object (File)
Oct 4 2024, 1:46 AM
Unknown Object (File)
Oct 4 2024, 1:43 AM
Subscribers

Details

Summary

See explanation here for why it's unsafe to copy-construct CryptoModule. Basically, the accountBuffer contains memory that represents an olm::Account, which includes members that are olm::Lists. olm::Lists contains a member that is a pointer to another member, which makes it unsafe to copy the accountBuffer wholesale.

Depends on D9561

Test Plan

I confirmed that after I saw compilation errors if I reverted the preceding diff (D9561)

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

Harbormaster returned this revision to the author for changes because remote builds failed.Oct 22 2023, 9:07 AM
Harbormaster failed remote builds in B23417: Diff 32298!

After reading this doc: https://en.cppreference.com/w/cpp/language/move_constructor
I am wondering if CryptoModule class has trivial move constructor that works like a default copy constructor. If that is the case we should consider deleting move constructor as well to entirely disable copying.

This revision is now accepted and ready to land.Oct 23 2023, 2:35 AM

I'm not sure if move construction is unsafe. I would actually assume it is safe. The question is whether std::vector (what we use for OlmBuffer) has a move constructor that allocates new space on the heap for the vector's data. I would assume it does not – the point of a move constructor is generally to avoid having to do that.