Byteswapping problems in usrp code

gnuradio/trunk/usrp/host/lib/legacy/usrp_bytesex.h includes byteswap.h,
which appears to be a Linux-specific header file. I looked briefly, and
didn’t see any POSIX/SUSv3 definitions of these macros. I just fixed
this to build on NetBSD, which I suspect also fixes it on several other
non-Linux systems.

NetBSD has bswap macros, in machine/bswap.h:

BSWAP(3) NetBSD Library Functions Manual
BSWAP(3)

NAME
bswap16, bswap32, bswap64 – byte-order swapping functions

LIBRARY
Standard C Library (libc, -lc)

SYNOPSIS
#include <sys/types.h>
#include <machine/bswap.h>

  uint16_t
  bswap16(uint16_t);

  uint32_t
  bswap32(uint32_t);

  uint64_t
  bswap64(uint64_t);

DESCRIPTION
The bswap16(), bswap32(), and bswap64() functions return the value
of
their argument with the bytes inverted. They can be used to
convert 16,
32 or 64 bits integers from little to big endian, or vice-versa.

SEE ALSO
byteorder(3)

NetBSD 4.0_BETA2 March 17, 1998 NetBSD
4.0_BETA2

Berndt sent a patch to the list to look for this; it seems equally
reasonable as the Linux header, neither being defined by a standard.

Also, the code uses ‘short int’ and ‘int’, which is nonportable. It
should be using the POSIX fixed-width types.

I wonder if the use of swap is really right - this seems to be about
host to USRP, but perhaps the USRP is always little endian? It
definitely needs more comments if that’s what’s going on.

On Mon, May 14, 2007 at 10:44:37AM -0400, Greg T. wrote:

gnuradio/trunk/usrp/host/lib/legacy/usrp_bytesex.h includes byteswap.h,
which appears to be a Linux-specific header file. I looked briefly, and
didn’t see any POSIX/SUSv3 definitions of these macros. I just fixed
this to build on NetBSD, which I suspect also fixes it on several other
non-Linux systems.

Also, the code uses ‘short int’ and ‘int’, which is nonportable. It
should be using the POSIX fixed-width types.

Agreed.

I wonder if the use of swap is really right - this seems to be about
host to USRP, but perhaps the USRP is always little endian? It
definitely needs more comments if that’s what’s going on.

The USRP is always little endian. We didn’t want to handle both cases
in the verilog, and at least at this point in history, most of our
hosts are little endian.

Eric