Re: [PATCH v2 0/6] bswap.h: Rework ntohl handling
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 7, 2025, 22:43 UTC
- Message-ID
- <xmqqo6tv1v1z.fsf@gitster.g>
- In-Reply-To
- <20250611221444.1567638-1-sebastian@breakpoint.cc>
Sebastian Andrzej Siewior <sebastian@breakpoint.cc> writes:
Show 23 quoted lines
> since the add of bswap32/64() support based on __builtin support, the > usage of ntohl() macros is broken on big endian machines because the > macros are always overwritten providing a swap. > > The first patch in the series reverts the change and the following > patches try to improve the situation by allowing to always provide an > optimized version. > > I've been looking at recent compiler and they manage to recognize the > manual shifting and use an optimize opcode if available. The ntohl > version provided by glibc already provides an "optimized" version which > makes an optimisation in git almost not needed. > One of the motivation behind overwriting/ providing an optimized > version was to provide a macro instead of using a function call. One > libc that is still providing ntohl as a function call is musl. So it > might makes sense to keep it. > While ntohl() is provided by the libc, the ntohll() is not. I found it > only on Windows provided by winsock.h. > > I haven't touched the put/get_be*() macros. gcc & clang are both smart > enough to swap the content accordingly and perform a single store/ load. > Only the msvc seems to strugle here and performs multiple bytes stores/ > loads and shifts.
Now, I see many comments and suggestions on the thread since this v2 iteration was posted:
https://lore.kernel.org/git/20250611221444.1567638-1-sebastian@breakpoint.cc/
and I think the ball is in the author's court to respond.
I'll mark the topic as Stalled in the draft of the next issue of "What's cooking" report.
Thanks.