Changing the Endiannes of an integer which can be 2,4 or 8 bytes using a switch-case statement

Question

In a (real time) system, computer 1 (big endian) gets an integer data from from computer 2 (which is little endian). Given the fact that we do not know the size of int, I check it using a sizeof() switch statement and use the __builtin_bswapX method accordingly as follows (assume that this builtin method is usable).

...
int data;
getData(&data); // not the actual function call. just represents what data is.
...
switch (sizeof(int)) {
case 2:
    intVal = __builtin_bswap16(data);
    break;
case 4:
    intVal = __builtin_bswap32(data);
    break;
case 8:
    intVal = __builtin_bswap64(data);
    break;
default:
    break;
}
...

is this a legitimate way of swapping the bytes for an integer data? Or is this switch-case statement totally unnecessary?

Update: I do not have access to the internals of getData() method, which communicates with the other computer and gets the data. It then just returns an integer data which needs to be byte-swapped.

Update 2: I realize that I caused some confusion. The two computers have the same int size but we do not know that size. I hope it makes sense now.

Answer 1

Seems odd to assume the size of int is the same on 2 machines yet compensate for variant endian encodings.

The below only informs the int size of the receiving side and not the sending side.

switch(sizeof(int))

---

The sizeof(int) is the size, in char of an int on the local machine. It should be sizeof(int)*CHAR_BIT to get the bit size. [Op has edited the post]

The sending machine should detail the data width, as a 16, 32, 64- bit without regard to its int size and the receiving end should be able to detect that value as part of the message or an agreed upon width should be used.

Much like hton() to convert from local endian to network endian, the integer size with these function is moving toward fixed width integers like

#include <netinet/in.h>

uint32_t htonl(uint32_t hostlong);
uint16_t htons(uint16_t hostshort);
uint32_t ntohl(uint32_t netlong);
uint16_t ntohs(uint16_t netshort);

So suggest sending/receiving the "int" as a 32-bit uint32_t in network endian.

---

[Edit]

Consider computers exist that have different endian (little and big are the most common, others exist) and various int sizes with bit width 32 (common), 16, 64 and maybe even some odd-ball 36 bit and such and room for growth to 128-bit. Let us assume N combinations. Rather than write code to convert from 1 of N to N different formats (N*N) routines, let us define a network format and fix its endian to big and bit-width to 32. Now each computer does not care nor need to know the int width/endian of the sender/recipient of data. Each platform get/receives data in a locally optimized method from its endian/int to network endian/int-width.

OP describes not knowing the the sender's int width yet hints that the int width on the sender/receiver might be the same as the local machine. If the int widths are specified to be the same and the endian are specified to be one big/one little as described, then OP's coding works.

However, such a "endians are opposite and int-width the same" seems very selective. I would prepare code to cope with a interchange standard (network standard) as certainly, even if today it is "opposite endian, same int", tomorrow will evolved to a network standard.

Answer 2

A portable approach would not depend on any machine properties, but only rely on mathematical operations and a definition of the communication protocol that is also hardware independent. For example, given that you want to store bytes in a defined way:

void serializeLittleEndian(uint8_t *buffer, uint32_t data) {
    size_t i;
    for (i = 0; i < sizeof(uint32_t); ++i) {
        buffer[i] = data % 256;
        data /= 256;
    }
}

and to restore that data to whatever machine:

uint32_t deserializeLittleEndian(uint8_t *buffer) {
    uint32_t data = 0;
    size_t i;
    for (i = 0; i < sizeof(uint32_t); ++i) {
        data *= 256;
        data += buffer[i];
    }
    return data;
}

EDIT: This is not portable to systems with other than 8 bits per byte due to the uses of int8_t and int32_t. The use of type int8_t implies a system with 8 bit chars. However, it will not compile for systems where these conditions are not met. Thanks to Olaf and Chqrlie.

Answer 3

Yes, this is totally cool - given you fix your switch for proper sizeof return values. One might be a little fancy and provide, for example, template specializations based on the size of int. But a switch like this is totally cool and will not produce any branches in optimized code.

Answer 4

As already mentioned, you generally want to define a protocol for communications across networks, which the hton/ntoh functions are mostly meant for. Network byte order is generally treated as big endian, which is what the hton/ntoh functions use. If the majority of your machines are little endian, it may be better to standardize on it instead though.

A couple people have been critical of using __builtin_bswap, which I personally consider fine as long you don't plan to target compilers that don't support it. Although, you may want to read Dan Luu's critique of intrinsics.

For completeness, I'm including a portable version of bswap that (at very least Clang) compiles into a bswap for x86(64).

#include <stddef.h>
#include <stdint.h>

size_t bswap(size_t x) {

  for (size_t i = 0; i < sizeof(size_t) >> 1; i++) {

    size_t d = sizeof(size_t) - i - 1;

    size_t mh = ((size_t) 0xff) << (d << 3);
    size_t ml = ((size_t) 0xff) << (i << 3);

    size_t h = x & mh;
    size_t l = x & ml;

    size_t t = (l << ((d - i) << 3)) | (h >> ((d - i) << 3));

    x = t | (x & ~(mh | ml));
  }

  return x;
}