wrong htons() used?
Mark Kettenis
kettenis@wins.uva.nl
Fri Oct 22 08:01:00 GMT 1999
Date: Fri, 22 Oct 1999 08:51:50 -0500
From: Grant.Edwards@comtrol.com
On Fri, Oct 22, 1999 at 10:34:04AM +1000, Andrew Cagney wrote:
> I think everyone has agreed that that isn't the problem that is occuring
> here.
I'm pretty sure that <netinet/in.h> is getting confused by one
of the include files in the rdi-remote directory, since that
directory is searched first for include files before
/usr/include.
The most likely candidate is the file `gdb/rdi-share/endian.h'. At
least on my system this file is masking `/usr/include/endian.h', which
defines __BYTE_ORDER. However, if you take a look at the following
fragment from <netinet/in.h> you'll notice that this shouldn't be a
problem since if __BYTE_ORDER isn't defined, no optimizing macro for
htons is defined:
#if __BYTE_ORDER == __BIG_ENDIAN && defined __OPTIMIZE__
/* The host byte order is the same as network byte order,
so these functions are all just identity. */
# define ntohl(x) (x)
# define ntohs(x) (x)
# define htonl(x) (x)
# define htons(x) (x)
#else
# if __BYTE_ORDER == __LITTLE_ENDIAN && defined __OPTIMIZE__
# define ntohl(x) __bswap_32 (x)
# define ntohs(x) __bswap_16 (x)
# define htonl(x) __bswap_32 (x)
# define htons(x) __bswap_16 (x)
# endif
#endif
Maybe your <netinet/in.h> is broken?
Anyway, I think that it is not wise to have a file named `endian.h' in
GDB. Not only will we lose certain useful optimizations, but this
file is also included by other libc or system headers.
Mark
More information about the Gdb
mailing list