On Fri, 9 Jan 2026 at 16:41, BALATON Zoltan <[email protected]> wrote:
>
> On Fri, 9 Jan 2026, Philippe Mathieu-Daudé wrote:
> > On 9/1/26 14:48, BALATON Zoltan wrote:
> >> On Fri, 9 Jan 2026, Philippe Mathieu-Daudé wrote:
> >>> Rename the API methods using the explicit 'unaligned'
> >>> description instead of 'he' which stands for 'host
> >>> endianness'.
> >>
> >> I still think it would be easier to add a comment somewhere (or in
> >> documentation) that host endian stands for no swap just use what the host
> >> uses (that also explains what be|le will swap relative to) and then not
> >> rename any of these. The le|be variants are also based he so do you rename
> >> those to lduw_le_unaligned_p too? This gets unwieldy. If you want to get
> >> rid of he at any rate then maybe just drop it and make the host endian
> >> variants lduw_p without any endian notation but I see no problem
> >
> > lduw_p() implicitly uses *guest* endianness... If we remove it first,
> > then w can have lduw_unaligned_p() become it. Quite some churn rework,
> > but I'm OK to pay the price if the community is willing to go in this
> > direction and we eventually get a clearer API.
>
> So then we could just leave it as "he" and document it better what it
> means, that seems to be the least churn to me. Adding unaligned only to
> the "he" variant does not seem to be improving naming as the others handle
> unaligned too so it's still unclear and renaming everyting would both be
> too long and too much churn. But if others think this improves it and is
> worth to do this rename for these he variants then I won't raise this
> again as I've explained my point sufficiently already. If nobody else
> cares then it's up to you.

I tend to agree with you -- _unaligned_ is rather long and obscures
that we have this family of related functions.

The "no endianness indicator in the function name means target endianness"
APIs are a bit of an unfortunate historical accident: we have ended
up with a fair few places where we'd probably prefer to use the _le_
or _be_ versions explicitly instead these days. We could perhaps
clean that up so they use a _te_ infix instead. I'm on the fence
about whether I think that worth the effort or not.

-- PMM

Reply via email to