On Wed, Oct 12, 2022, Colton Lewis wrote:
> Sean Christopherson <seanjc@xxxxxxxxxx> writes:
> > The code is trivial to write and I can't think of any meaningful downside.
> > Worst case scenario, we end up with an implementation that is slightly more
> > formal than then we really need.
>
> As a matter of personal taste, I don't like the additional formality
> making things look more complicated than they are. The stakes are small
> here but that kind of extra boilerplate can add up to make things
> confusing.
I agree about unnecessary boilerplate being a burden, especially when it comes to
KVM selftests, which are ridiculously "formal" and make simple operations
frustratingly difficult.
In this case though, I think the benefits of encapsulating the seed outweigh the
cost of the formality by a good margin, and I don't see that formality snowballing
any further. A struct gets us:
- Type checking on the input param, e.g. prevents passing in garbage for the seed.
- The ability to switch out the algorithm.
- Some protection against overwriting the seed, e.g. corrupting the struct pointer
will explode and a memcpy() to overwrite the struct will be more visibily wrong.
> Thanks for your patience. I never wanted to cause trouble.
Heh, no worries.
