Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 09 Dec 2002 10:20:10 -0700 (MST)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        rizzo@icir.org
Cc:        arch@FreeBSD.ORG
Subject:   Re: le??toh, etc in userland
Message-ID:  <20021209.102010.127953437.imp@bsdimp.com>
In-Reply-To: <20021209090523.A75689@xorpc.icir.org>
References:  <20021209.095032.102181079.imp@bsdimp.com> <20021209090523.A75689@xorpc.icir.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20021209090523.A75689@xorpc.icir.org>
            Luigi Rizzo <rizzo@icir.org> writes:
: On Mon, Dec 09, 2002 at 09:50:32AM -0700, M. Warner Losh wrote:
: > We should provide an implementation of {b,l}e{16,32}toh and
: > hto{b,l}e{16,32} in libc.  Any objections?
: 
: I have one on the names.
: 
: Historical functions (htonl(), ntohs() and friend) put the operand
: size at the end, and this to me makes sense because the size refers
: to both operands.
: The names you propose link the size to the {b,l}e operand only.
: Does it mean that we have the following interfaces ?
: 
: 	int be16toh(u_int16_t)		int le16toh(u_int16_t)
: 	int be32toh(u_int32_t)		int le32toh(u_int32_t)
: 	u_int16_t htobe16(int)		u_int16_t htole16(int)
: 	u_int32_t htobe32(int)		u_int32_t htole32(int)
: 
: (i.e. the host side has the same type) ?

Not quite.  The proper prototypes are:

uint16_t be16toh(uint16_t)
uint16_t le16toh(uint16_t)
uint32_t be32toh(uint32_t)
uint32_t le32toh(uint32_t)
uint64_t be64toh(uint64_t)
uint64_t le64toh(uint64_t)

uint16_t htobe16(uint16_t)
uint16_t htole16(uint16_t)
uint32_t htobe32(uint32_t)
uint32_t htole32(uint32_t)
uint64_t htobe64(uint64_t)
uint64_t htole64(uint64_t)

These macros are strictly for swapping the bytes from a certain endian
to the host's endian, without changing the type.

: I remember last time we discussed the issue on the kernel you said
: that it was too late to change, but if we don't have such APIs in
: userland, then we could at least use a more consistent naming scheme.

I'm saying that we provide the __bswap{16,32} functions.  I've since
discovered that we need to do the 64 bit version too.

I'm open to revisiting the name issue, but only to the extent of
providing both names.  Since I'm sharing code with NetBSD right now,
and we've already done a release with the NetBSD names, there's no way
I'd support killing the NetBSD names.  Also, I need these functions to
support building NetBSD on FreeBSD (we're a lot closer than we were
the last time I tried this).

Also, I shouldn't have send the mail as soon as I did, because at
least on i386 the __bswap* functions are defined inline and there was
a different reason why I missed it.

Warner

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021209.102010.127953437.imp>