[PATCH 1/1] inet: add support for 64-bit network byte order

[Joseph Myers]

On Sun, 9 Mar 2025, Philip Prindeville wrote:

> diff --git a/conform/data/arpa/inet.h-data b/conform/data/arpa/inet.h-data
> index 040b8212c73778d2e1272a2841424fdb098ddde2..c80912ffde59e1d6da1c548f3a0e072f4b4ab5f6 100644
> --- a/conform/data/arpa/inet.h-data
> +++ b/conform/data/arpa/inet.h-data
> @@ -11,8 +11,10 @@ macro INET_ADDRSTRLEN
>  macro INET6_ADDRSTRLEN
>  
>  // The following can be declared as functions, defined as macros or both:
> +function uint64_t htonll (uint64_t)
>  function uint32_t htonl (uint32_t)
>  function uint16_t htons (uint16_t)
> +function uint64_t ntohll (uint64_t)
>  function uint32_t ntohl (uint32_t)
>  function uint16_t htons (uint16_t)
>  
> diff --git a/conform/data/netinet/in.h-data b/conform/data/netinet/in.h-data
> index ccc74db608727200161d2713a2f7fb171d8b8138..27a8628a99f749e69c0b6456fb875da5cd8da367 100644
> --- a/conform/data/netinet/in.h-data
> +++ b/conform/data/netinet/in.h-data
> @@ -53,8 +53,10 @@ macro INADDR_BROADCAST
>  
>  constant INET_ADDRSTRLEN == 16
>  
> +function uint64_t htonll (uint64_t)
>  function uint32_t htonl (uint32_t)
>  function uint16_t htons (uint16_t)
> +function uint64_t ntohll (uint64_t)
>  function uint32_t ntohl (uint32_t)
>  function uint16_t ntohs (uint16_t)

conform/ is only for things that are actually in one of the supported 
versions of standards, not for GNU extensions and not possible future 
standard features.  Adding things to this section of these files is 
asserting that those features were in UNIX98, in POSIX.1-2001 with X/Open 
extensions, and in POSIX.1-2008 both with and without X/Open extensions.  
Unless you've verified the interfaces were in all those standards, they 
don't belong in that place in those files.

Similarly, the declarations need to be conditional on __USE_GNU in the 
headers unless in all standards that support those headers.

I'd argue that the "network" byte order naming is not particularly 
user-friendly (and nor, for that matter, is the "ll"/"l"/"s" naming).  
Rather, we already have names such as htobe64 in <endian.h> as extensions 
under __USE_MISC and those ought to suffice, without adding less-friendly 
names such as these, unless some actual standard has those names.

Note that POSIX.1-2024 added <endian.h> with the functions such as 
htobe64, which is further evidence against adding these extensions using 
an older naming convention.  (glibc hasn't yet been systematically updated 
for POSIX.1-2024, nor have conform/ tests had support for that standard 
added.)

> +@deftypefun {uint64_t} htonll (uint64_t @var{hostlonglong})
> +@standards{BSD, netinet/in.h}

Saying "BSD" is only appropriate for things that actually came from BSD 
(which I think in this context means 4.4 BSD not anything more recent).  
Did 4.4 BSD have the functions you are adding?

-- 
Joseph S. Myers
josmyers@redhat.com