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.