Ole32: le32toh/le16toh conflict in storage32.h's endian macros

[Austin English]

In file included from storage32.c:50:
storage32.h:406:1: warning: "le32toh" redefined
In file included from /usr/include/machine/endian.h:3,
                 from /usr/include/sys/types.h:98,
                 from /usr/include/stdlib.h:41,
                 from storage32.c:36:
/usr/include/sys/endian.h:178:1: warning: this is the location of the
previous definition

There are a four of these warnings. Apparently Wine defines these in
storage32.h:
/*********************************************************
 * Endian conversion macros
 */
#ifdef WORDS_BIGENDIAN

#define htole32(x) RtlUlongByteSwap(x)
#define htole16(x) RtlUshortByteSwap(x)
#define le32toh(x) RtlUlongByteSwap(x)
#define le16toh(x) RtlUshortByteSwap(x)

#else

#define htole32(x) (x)
#define htole16(x) (x)
#define le32toh(x) (x)
#define le16toh(x) (x)

#endif

And on NetBSD:
#if BYTE_ORDER == BIG_ENDIAN

#define htole16(x)      bswap16((uint16_t)(x))
#define htole32(x)      bswap32((uint32_t)(x))
#define htole64(x)      bswap64((uint64_t)(x))
...
#define HTOLE16(x)      (x) = bswap16((uint16_t)(x))
#define HTOLE32(x)      (x) = bswap32((uint32_t)(x))
#define HTOLE64(x)      (x) = bswap64((uint64_t)(x))
...
#else   /* LITTLE_ENDIAN */
...
#define htole16(x)      (x)
#define htole32(x)      (x)
#define htole64(x)      (x)
...
#define HTOLE16(x)      (void) (x)
#define HTOLE32(x)      (void) (x)
#define HTOLE64(x)      (void) (x)

I started to send a patch to #ifdef,#undef, but I'm not sure that's
right...which definition should we be using here, NetBSD's or Wine's?

Furthermore, do we need to add le64toh/htole64?

[Juan Lang]

Hi Austin,
> I started to send a patch to #ifdef,#undef, but I'm not sure that's
> right...which definition should we be using here, NetBSD's or Wine's?

It doesn't really matter.  I came up with the names as a shorthand for
the longer Win32 (well, ntdll really) name, and also to be able to
define them as a no-op on little-endian machines.  You can come up
with a name that doesn't conflict and replace those definitions if you
like.  That has the advantage of not breaking it on big-endian machine
on which le32toh et al aren't defined.
> Furthermore, do we need to add le64toh/htole64?

Not unless you see a need.  I didn't see any 64-bit types in the
property storage when I was working on it.
--Juan