Re: [PATCH v3 0/5] bswap.h: Rework ntohl handling
- From
Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
- Date
- Jul 16, 2025, 05:01 UTC
- Message-ID
- <20250716050111.cw6zt2Vs@breakpoint.cc>
- In-Reply-To
- <xmqqple1f7ge.fsf@gitster.g>
On 2025-07-15 14:52:01 [-0700], Junio C Hamano wrote:
Show 25 quoted lines
> Sebastian Andrzej Siewior <sebastian@breakpoint.cc> writes: > > > this series continues the rework of the bswap32/64()/ nothl() handling. > > > > 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. > > > > 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. > > > > v2…v3 https://lore.kernel.org/all/20250611221444.1567638-1-sebastian@breakpoint.cc/ > > - Fixed typos in the patch description > > Thanks for updating the proposed log messages with typofixes. I > understand the patch text has no changes?
The patches iteself remain unchanged, only the patch description of a few got updated. There was only one comment regarding using endian(3). At the same time I got the feeling to first get this through and then we can think how to continue further. glibc optimizes ntohl already so git might not have to. I only found musl that has a function call. I didn't look on *BSD. It just something is needed for ntohll().
> Thanks.
Sebastian