EncodeUint256 only uses 32 bytes exactly (plus one for the size). It only ever gets passed that throughout the code. It's better to leave it at that or add additional checks to ensure this to make it more robust

EncodeUint256 only uses 32 bytes exactly (plus one for the size). It only ever gets passed that throughout the code. It's better to leave it at that or add additional checks to ensure this to make it more robust

Well, this PR is making EncodeUint256 more robust (now it works with any buffer whose length >= 32).

Yes but if the calling code wants to pass a bigger byte slice, it already knows what it's doing, and should pass 32 instead. Otherwise, it might as well pass 31 or less, in which case it will break.

EncodeUint256 only uses 32 bytes exactly (plus one for the size). It only ever gets passed that throughout the code. It's better to leave it at that or add additional checks to ensure this to make it more robust

Well, this PR is making EncodeUint256 more robust (now it works with any buffer whose length >= 32).

It's a matter of taste, of course, but here I'm following the robustness principle "be conservative in what you do, be liberal in what you accept from others". We could make EncodeUint256 return an error for buffers longer than 32 bytes, but I don't see a point because the function can work with such buffers just fine.

The case when a buffer shorter than 32 bytes is passed is probably easier to detect because it'll panic.