NetBSD Problem Report #57478

From www@netbsd.org  Thu Jun 22 03:48:47 2023
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 92ABB1A923E
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 22 Jun 2023 03:48:47 +0000 (UTC)
Message-Id: <20230622034846.227A01A9241@mollari.NetBSD.org>
Date: Thu, 22 Jun 2023 03:48:46 +0000 (UTC)
From: rin@iij.ad.jp
Reply-To: rin@iij.ad.jp
To: gnats-bugs@NetBSD.org
Subject: ntohs(3) and friends behave differently to manpage for big endian
X-Send-Pr-Version: www-1.0

>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:          needs-pullups
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 22 03:50:00 +0000 2023
>Closed-Date:    
>Last-Modified:  Sat Apr 12 13:00:02 +0000 2025
>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.

>Release-Note:

>Audit-Trail:
From: "Rin Okuyama" <rin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/57478 CVS commit: src/sys/sys
Date: Fri, 4 Apr 2025 04:23:29 +0000

 Module Name:	src
 Committed By:	rin
 Date:		Fri Apr  4 04:23:29 UTC 2025

 Modified Files:
 	src/sys/sys: endian.h

 Log Message:
 endian.h: Consistently use __CAST() where appropriate, NFC

 In preparation for PR lib/57478


 To generate a diff of this commit:
 cvs rdiff -u -r1.35 -r1.36 src/sys/sys/endian.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Rin Okuyama" <rin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/57478 CVS commit: src/sys/sys
Date: Fri, 4 Apr 2025 04:37:32 +0000

 Module Name:	src
 Committed By:	rin
 Date:		Fri Apr  4 04:37:32 UTC 2025

 Modified Files:
 	src/sys/sys: endian.h

 Log Message:
 endian.h: Cast to suitable type when byte order conversion is NOP

 Otherwise, e.g., following examples do not work as expected on
 big-endian machines:

 - printf("%x\n", ntohl(0x01234567890abcdefULL);
 - uint64_t u64 = ntohl(0x01234567890abcdefULL);
 - etc.

 Fix PR lib/57478

 I've been tested this patch both on big-/little-endian and
 LP64/ILP32 environments over a year without troubles.

 I will request to pull this up into netbsd-10 at least,
 if there's no unexpected fallout.


 To generate a diff of this commit:
 cvs rdiff -u -r1.36 -r1.37 src/sys/sys/endian.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->needs-pullups
State-Changed-By: rin@NetBSD.org
State-Changed-When: Fri, 04 Apr 2025 04:48:18 +0000
State-Changed-Why:
Fixed for -current with similar cases not described in the
original PR, namely:

* For big-endain:
- ntoh{l,s}
- hton{l,s}
- htobe{16,32,64}

* For little-endian:
- htole{16,32,64}

I will send pullup request to netbsd-10 after seeing there's
no unexpected fallout for a while.


From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/57478 CVS commit: [netbsd-10] src/sys/sys
Date: Sat, 12 Apr 2025 12:56:48 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Sat Apr 12 12:56:48 UTC 2025

 Modified Files:
 	src/sys/sys [netbsd-10]: endian.h

 Log Message:
 Pull up following revision(s) (requested by rin in ticket #1095):

 	sys/sys/endian.h: revision 1.36
 	sys/sys/endian.h: revision 1.37

 endian.h: Consistently use __CAST() where appropriate, NFC

 In preparation for PR lib/57478
 endian.h: Cast to suitable type when byte order conversion is NOP

 Otherwise, e.g., following examples do not work as expected on
 big-endian machines:
 - printf("%x\n", ntohl(0x01234567890abcdefULL);
 - uint64_t u64 = ntohl(0x01234567890abcdefULL);
 - etc.

 Fix PR lib/57478

 I've been tested this patch both on big-/little-endian and
 LP64/ILP32 environments over a year without troubles.


 To generate a diff of this commit:
 cvs rdiff -u -r1.31.4.1 -r1.31.4.2 src/sys/sys/endian.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search