Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cpp: Fix evmc::result's move assignment operator #282

Merged
merged 4 commits into from
May 15, 2019
Merged

Conversation

chfast
Copy link
Member

@chfast chfast commented May 14, 2019

No description provided.

@chfast chfast changed the base branch from master to release/6.2 May 14, 2019 10:04
@chfast chfast requested review from gumb0 and halfalicious May 14, 2019 10:08
@chfast chfast force-pushed the fix_result_move branch 2 times, most recently from 140e700 to 152aaca Compare May 14, 2019 12:47
@@ -39,25 +39,29 @@ class result : private evmc_result
/// Move constructor.
result(result&& other) noexcept : evmc_result{other}
{
// Disable releaser of the rvalue object.
other.release = nullptr;
other.release = nullptr; // Disable releasing of the rvalue object.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should you do also other.output_data = nullptr to avoid dangling other?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was considering zeroing the other, but using an object that has been moved is an error anyway. I decided not to because there are other cases which will be hard to cover. Fortunately, some compilers warn you about using an object after std::move().

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For raw() there are no language rules though, and after calling raw() this contains dangling pointer

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a number of things we can do about it.

  1. This is already documented.
  2. The function is rather internal, needed to the Host interface. We might hide it by making it private and friend with the Host.
  3. We can zero the other in raw(). It might be better than the current but still not protecting against using the object after raw() (it might actually hide the problem deeper) and that will set the .status_code to EVMC_SUCCESS.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could zero out everything but status_code.

Anyway I don't think it's super-critical, having it documented might be enough.
(maybe I would name it release() to be similar to smart pointers)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

release()

I wanted that, but unfortunately evmc_result already has the release method. I wander how to rename it to make the usage more obvious. release_raw()? move_raw()? take_raw()?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

release_raw sounds better to me than raw

@chfast chfast force-pushed the fix_result_move branch from 152aaca to d9a6a8b Compare May 14, 2019 16:01
@chfast chfast marked this pull request as ready for review May 14, 2019 16:01
@chfast chfast requested a review from axic May 14, 2019 16:01
Copy link
Member

@axic axic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can judge C++ subtleties this looks OK to me, but wouldn't merge it before @gumb0 says yes.

@chfast chfast merged commit 703b661 into release/6.2 May 15, 2019
@chfast chfast deleted the fix_result_move branch May 15, 2019 14:42
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.

3 participants