Thread: Some remaining htonl() and ntohl() calls in the code

Some remaining htonl() and ntohl() calls in the code

From
Michael Paquier
Date:
Hi all,

Since 510b8cbf, we have in-core equivalents for htonl(), ntohl() & co
through pg_bswap.h that allows to compile with a built-in function if
the compiler used has one.

All the existing calls in the code tree have been changed with
0ba99c84 for performance reasons (except the libpq examples), however
the FE/BE code of GSSAPI encryption code did not get this call in
b0b39f7.  I think that we had better switch to the built-ins functions
as well for this case.  The argument of consistency matters here, but
also perhaps the argument of performance, where it may not be easy to
measure a difference.

Attached is a patch to do the switch.  None of the files changed
include arpa/inet.h.  Any thoughts?

Thanks,
--
Michael

Attachment

Re: Some remaining htonl() and ntohl() calls in the code

From
Andres Freund
Date:
Hi,

On 2020-10-14 14:53:03 +0900, Michael Paquier wrote:
> Since 510b8cbf, we have in-core equivalents for htonl(), ntohl() & co
> through pg_bswap.h that allows to compile with a built-in function if
> the compiler used has one.
> 
> All the existing calls in the code tree have been changed with
> 0ba99c84 for performance reasons (except the libpq examples), however
> the FE/BE code of GSSAPI encryption code did not get this call in
> b0b39f7.  I think that we had better switch to the built-ins functions
> as well for this case.  The argument of consistency matters here, but
> also perhaps the argument of performance, where it may not be easy to
> measure a difference.

+1

Greetings,

Andres Freund



Re: Some remaining htonl() and ntohl() calls in the code

From
Michael Paquier
Date:
On Wed, Oct 14, 2020 at 01:41:23PM -0700, Andres Freund wrote:
> +1

Thanks.  I have applied that as of 86dba33, and did not see a need for
a back-patch.
--
Michael

Attachment