On Wed Oct 7, 2026 at 8:56 PM JST, Alexandre Courbot wrote: > On Wed Oct 7, 2026 at 8:33 PM JST, John Hubbard wrote: >> On 10/7/26 5:48 AM, Alexandre Courbot wrote: >>> On Wed Oct 7, 2026 at 12:43 PM JST, Alexandre Courbot wrote: >>>> On Mon Sep 28, 2026 at 5:42 PM JST, Eliot Courtney wrote: >>>> <...> >>>> ... and that's all I could find on this patch. I particularly like how >>>> the examples have turned out! >>> >>> ... although maybe the Sashiko comments are worth considering too. Nova >>> does depend on little-endian, but it probably wouldn't cost us much to >>> e.g. call `to_le_bytes` instead of `to_ne_bytes` to make the code more >>> portable. >> >> I recall having this conversation before, and I've tried to consistently >> say "no". It's not a real thing, and if it ever becomes one it will be >> a very big deal, not something we would overlook. > > I agree on principle when writing endian-neutral code requires some > extra infrastructure or considerably more code, but here we are talking > about trading a call to `to_ne_bytes` for one to `to_le_bytes`, which is > zero effort. > > ... although the Sashiko warning on `extend_with_padding` *would* > require more than just a method call to properly manage arrays of `u32` > and `u64`, so maybe we don't need to fix them all, or any at all for > that matter since half-fixed code is still broken code.
If I see some code that is explicitly written to handle endianness, it's confusing, because it implies that some or all of the code is meant to work with variable endianness. But that's not the case, and would leave me wondering why just this bit was written in an endianness-neutral way. I think we agree on this part though. For the case where it requires no extra effort, e.g. `to_ne_bytes` vs `to_le_bytes`, I think we shouldn't use review time on it. So IMO `to_le_bytes` is conceptually slightly more correct here because NVKV is little endian regardless of the host CPU, but I would not want to use review time on this in the future because: 1. it's wonky to change just some of the handling, and changing more (as you've noted) can require extra infra/copies/affect performance. 2. I think assessing each `to_*_bytes` call every time it comes up for which one is more conceptually correct (is it host-related, or GSP-related, or if it's both, which one to choose since we're not going to bother adding extra infra for it) is just gonna waste review time.
