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

Add CT::Choice::yes() and ::no() #4154

Merged
merged 1 commit into from
Jun 28, 2024

Conversation

reneme
Copy link
Collaborator

@reneme reneme commented Jun 27, 2024

Allow creating a CT::Choice representing true or false (e.g. for unit testing). Also: restrict CT::Choice::from_int() to not work for bool as this produces compiler warnings* and is probably undesired (i.e. a code-smell) anyway. I need those for the requested adaptions to bitvector<> in #3107.

[*] The compiler is complaining that we try to negate a bool using ~ instead of !.

@reneme reneme added this to the Botan 3.5.0 milestone Jun 27, 2024
@reneme reneme requested a review from randombit June 27, 2024 12:52
@reneme reneme self-assigned this Jun 27, 2024
@coveralls
Copy link

Coverage Status

coverage: 91.72% (+0.004%) from 91.716%
when pulling 3790e4d on Rohde-Schwarz:rene/choice_factories
into 92c2079 on randombit:master.

@@ -134,6 +135,10 @@ class Choice final {
return Choice(ct_is_zero<uint32_t>(static_cast<uint32_t>(v_is_0)));
}

constexpr static Choice yes() { return Choice::from_int(1U); }

constexpr static Choice no() { return Choice::from_int(0U); }
Copy link
Owner

Choose a reason for hiding this comment

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

These could just directly initialize the masked values (either all zero or all ones resp), no need for them to be guarded by the value barrier.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Given that the constexpr-ness of the factory those delegate to, I was hoping that the compiler would do that for me and not actually compile a value barrier. But yeah, no harm in doing that explicitly.

Copy link
Owner

Choose a reason for hiding this comment

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

That would only apply if you created the variable as constexpr though, right?

constexpr auto yes = Choice::yes(); // compile time evaluated, no value barrier
const auto yes = Choice::yes(); // evaluted at runtime, presumably with value barrier

... to allow creating true/false choices (e.g. for unit testing)
@coveralls
Copy link

Coverage Status

coverage: 91.724% (+0.008%) from 91.716%
when pulling d6b166b on Rohde-Schwarz:rene/choice_factories
into 92c2079 on randombit:master.

@randombit
Copy link
Owner

BTW agree that we don't want/need any obvious conversion from bool -> Choice, since if the sensitive value is already a bool then it's too late, you've been eaten by the value range propagator.

@reneme reneme merged commit 6aef983 into randombit:master Jun 28, 2024
42 checks passed
@reneme reneme deleted the rene/choice_factories branch June 28, 2024 10:25
@reneme reneme mentioned this pull request Jun 28, 2024
14 tasks
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