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.

There's nothing magical happening, it's all within your code. Read it one byte at a time and you'll see that it is as it should be.
You haven't shown the code for buffer_add_int16.
Just step through both functions with a debugger. If there's something wrong you'll spot it soon enough.

Code:

---

word ChangeEndianness(word temp){
  char junk;
 
  junk = *(char*)&temp;
  temp << 8;
  temp = temp | junk;
 
  return temp;
  }

---

or

Code:

---


word ChangeEndianness_Fast(word temp){

  __asm {
      mov ax , temp
      xchg ah , al
      mov temp , ax
      }

  return temp;
  }

---

Quote:

---

Originally Posted by abachler

Code:

---

word ChangeEndianness(word temp){
  char junk;
 
  junk = *(char*)&temp;
  temp << 8;
  temp = temp | junk;
 
  return temp;
  }

---

or

Code:

---


word ChangeEndianness_Fast(word temp){

  __asm {
      mov ax , temp
      xchg ah , al
      mov temp , ax
      }

  return temp;
  }

---

---

Why reinvent the wheel? Just use ntohs() & htons()...

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 :confused:

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.

Quote:

---

Originally Posted by abachler

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

---

And you have measured the existing ntohs() etc, and found that your code is faster? Because I've at least seen some implementatins where the macro expansion or code in the function does something very similar to what you posted here - so I'm not sure there's much to be gained.

--
Mats