BSD getaddrinfo() endianness - c

Question

I am trying to familiarize myself with the networking BSD API. I understand the fact that multi bytes data submitted to the BSD API (like address and port) must be in network byte order and that we should use converting functions like htons() and htonl() to do this. This snippet of code shows that:
#define IP_ADDRESS(a, b, c, d) ((((uint32_t)a) << 24) | (((uint32_t)b) << 16) | (((uint32_t)c) << 8) | ((uint32_t)d))
/* Set server port in BSD format */
memset(&serverAddr, 0, sizeof(serverAddr));
serverAddr.sin_family = AF_INET;
serverAddr.sin_addr.s_addr = htonl(IP_ADDRESS(192,168,1,1));
serverAddr.sin_port = htons(21);
/* Connect to server */
status = connect(H->bsdSocket, (struct sockaddr *)&serverAddr, sizeof(serverAddr));
Now I am trying to make use of getaddrinfo() in order to retrieve the address information from a server name. I tried that following code:
memset( &hints, 0, sizeof( hints ) );
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = IPPROTO_TCP;
getaddrinfo( "srvdc01", "21", &hints, &addr_list );
if (addr_list != NULL)
{
ctx->fd = (int) socket( addr_list->ai_family, addr_list->ai_socktype,
addr_list->ai_protocol );
if (ctx->fd >= 0)
status = connect( ctx->fd, addr_list->ai_addr, addr_list->ai_addrlen );
}
I would have expected that the address returned by getaddrinfo() would be in network byte order in such a way it could be fed directly to the connect() function. Unfortunately, this does not work with the library I am using as the resulting connect is reverting the address bytes (I use Wireshark to investigate this issue).
Is it allowed to safely use addresses returned by getaddrinfo() for feeding the socket() and connect() calls?
Thanks, Franck
=== Update ===
Thanks guys for your comments. I could clarify things a little more. I ran the following code snippet with the following results:
struct addrinfo hints, *addr_list, *cur;
struct sockaddr_in addr_in;
memset(&addr_in, 0, sizeof(addr_in));
addr_in.sin_family = AF_INET;
addr_in.sin_port = htons(21);
addr_in.sin_addr.s_addr = htonl(0xC0A80101UL); // 192.168.1.1
myprintf("%08x\n", addr_in.sin_addr.s_addr);
hints.ai_family = AF_INET;
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = IPPROTO_TCP;
if( getaddrinfo( "srvdc01", "21", &hints, &addr_list ) == 0 )
{
for( cur = addr_list; cur != NULL; cur = cur->ai_next )
{
ctx->fd = (int) socket( cur->ai_family, cur->ai_socktype,
cur->ai_protocol );
if( ctx->fd >= 0 )
{
myprintf("%08x\n", ((struct sockaddr_in *)cur->ai_addr)->sin_addr.s_addr);
}
}
}
freeaddrinfo( addr_list );
The first printf output (after htonl) gives c0a80101 while the second one (after socket creation) gives 0101a8c0. This was surprising because on my little endian platform, I would have expected the htonl() call to swap bytes to bring them in network byte order.
After reviewing documentation of our embedded networking library (third party commercial library), we could find that the BSD API they provide is actually a (quite) limited wrapper on top of their vendor specific network library API. There is a small notice about the fact that their library always work with the native system endianness so their htonl() function is always a dummy call that does nothing.
Now, looking at the link provided by Martin R. http://pubs.opengroup.org/onlinepubs/009695399/functions/freeaddrinfo.html, I agree with him that getaddrinfo() should return an address information suitable for a call to connect() which is visibly not the case with this embedded library.

Answer 1

The POSIX documentation for getaddrinfo()
states that
Upon successful return of getaddrinfo(), the location to which res points shall refer to a linked list of addrinfo structures, each of which shall specify a socket address and information for use in creating a socket with which to use that socket address. The list shall include at least one addrinfo structure. The ai_next field of each structure contains a pointer to the next structure on the list, or a null pointer if it is the last structure on the list. Each structure on the list shall include values for use with a call to the socket() function, and a socket address for use with the connect() function or, if the AI_PASSIVE flag was specified, for use with the bind() function. The fields ai_family, ai_socktype, and ai_protocol shall be usable as the arguments to the socket() function to create a socket suitable for use with the returned address. The fields ai_addr and ai_addrlen are usable as the arguments to the connect() or bind() functions with such a socket, according to the AI_PASSIVE flag.
This implies that – on a POSIX compliant system – IP address and port number in ai_addr are
in network byteorder, as expected by the connect() function.