lib/57478: ntohs(3) and friends behave differently to manpage for big endian

[rin%iij.ad.jp@localhost]

>Number:         57478
>Category:       lib
>Synopsis:       ntohs(3) and friends behave differently to manpage for big endian
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 22 03:50:00 +0000 2023
>Originator:     Rin Okuyama
>Release:        10.99.3
>Organization:
Internet Initiative Japan Inc.
>Environment:
NetBSD console 10.99.3 NetBSD 10.99.3 (SUNXI_NET_MPSAFE) #0: Mon May 22 11:10:46 JST 2023  rin@latipes:/build/src/sys/arch/evbarm/compile/SUNXI_NET_MPSAFE evbarm earmv7hfeb
>Description:
ntohs(3) reads:

----
     uint16_t
     ntohs(uint16_t net16);
----

However, it is defined for big endian machines as:

<sys/endian.h>:
----
...
   112  #if BYTE_ORDER == BIG_ENDIAN && !defined(__lint__)
   113  #define ntohl(x)        (x)
   114  #define ntohs(x)        (x)
   115  #define htonl(x)        (x)
   116  #define htons(x)        (x)
...
----

Therefore, ntohs(0x11111111) yeilds 0x11111111 on big endian machines.

This behavior is apparently inconsistent with its manpage (and
POSIX). However, this should be a REALLY old bug, and I'm not 100%
sure whether it is safe to correct this.
>How-To-Repeat:
Compile and run this sample code:

----
#include <sys/endian.h>

#include <stdio.h>

int
main(void)
{
	int i;

	i = ntohs(0x11111111);
	printf("0x%08x\n", i);
	return 0;
}
----

0x00001111 and 0x11111111 are obtained for amd64 and earmv7hf-eb,
respectively.
>Fix:
#define ntohs(x) ((uint16_t)(x)) and so on.