-
Notifications
You must be signed in to change notification settings - Fork 570
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
Conversation
src/lib/utils/ct_utils.h
Outdated
@@ -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); } |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
3790e4d
to
d6b166b
Compare
BTW agree that we don't want/need any obvious conversion from |
Allow creating a
CT::Choice
representing true or false (e.g. for unit testing). Also: restrictCT::Choice::from_int()
to not work forbool
as this produces compiler warnings* and is probably undesired (i.e. a code-smell) anyway. I need those for the requested adaptions tobitvector<>
in #3107.[*] The compiler is complaining that we try to negate a bool using
~
instead of!
.