Thread: Endian Question

I am writing a data buffer which will handle data that will be sent out on a socket stream. So needless to say, it will be in a big endian format because that is the network standard.

The following code puts this data in correctly:

Code:

buffer_add_int16(sendbuff, 0xBBCC);

If I look at the buffer byte for byte, it is in the order 0xBB 0xCC, which is good.

The problem comes along when I try to read it out of the buffer. My system is little endian.
Here is my function for reading out a WORD sized datatype:

Code:

uint16_t buffer_get_int16(buffer_t *buffer)
{
	uint16_t ret;

	buffer_get_bytes(buffer, buffer->buffer_position, &ret, 2);
	buffer->buffer_position+=2;
	
	if (__BYTE_ORDER == buffer->buffer_byte_order)
		return ret;
	else
		return ntohs(ret);
}

void *buffer_get_bytes(buffer_t *buffer, uint16_t offset, void *data, uint16_t length)
{
	memcpy(data, buffer->buffer_data + offset, length);
	return data;
}

I have checked, and __BYTE_ORDER == buffer->buffer_byte_order is false, so it sends ret through ntohs. But doing this gives it to me in big endian, which is what I don't want.

Really all I am asking is there something done under the hood that automatically converts it to little endian when I pull it out of the buffer?

Strange.
Maybe try to reverse the byte order by yourself instead of doing that with ntohs. Like:

Code:

memcpy(data, buffer->buffer_data + offset + 1, 1);
memcpy(data + 1, buffer->buffer_data + offset, 1);

And check again.

Because I dont like the whole wheel thing, its too roundy, I want something thats more efficient.

Are you using the loopback address mechanism or are you actually sending the data over the wire ie sending and receiving hosts are different

The interface is simple enough to spare those manual checkings, you don't even have to know your host encoding or the network encoding, simply use htons/nl() when you send a 16 or 32 bits integer and ntohs/l() when you receive it. This is the portable way. Besides, if you _know_ the sender and the receiver have the same architecture (let's say intel-like), you don't even have to encode/decode it... just ensure the header part of the packets is correctly encoded, your data is not used by the network layers anyway.