Преобразование порядка байтов без использования неопределенного поведения

Я не вижу настоящего UB в коде OP.

Проблемы с переносимостью: да.

"каламбур, который может не работать так же хорошо в других системах" не является проблемой для кода C OP, но может вызвать проблемы с другими языками.

А как насчет большого (PNG) порядка байтов для размещения?

Извлеките байты по адресу (от младшего адреса, у которого есть MSByte до самого высокого адреса, у которого есть LSByte - «большой» порядок байтов) и сформируйте результат со смещенными байтами.

Что-то типа:

uint32_t Endian_BigToHost32(uint32_t val) {
  union {
    uint32_t u32;
    uint8_t u8[sizeof(uint32_t)]; // uint8_t insures a byte is 8 bits.
  } x = { .u32 = val };
  return 
      ((uint32_t)x.u8[0] << 24) |
      ((uint32_t)x.u8[1] << 16) |
      ((uint32_t)x.u8[2] <<  8) |
                 x.u8[3];
}

Совет: во многих библиотеках есть функция, специфичная для реализации. Пример be32toh.

ИМО, было бы лучше читать из байтов в желаемый формат, чем, по-видимому, memcpy'ing a uint32_t, а затем внутренне манипулировать uint32_t. Код может выглядеть так:

uint32_t read_be32(uint8_t *src)   // must be unsigned input
{
     return (src[0] * 0x1000000u) + (src[1] * 0x10000u) + (src[2] * 0x100u) + src[3];
}

Довольно легко ошибиться в подобном коде, поэтому убедитесь, что вы получили его от высокопоставленных пользователей SO ????. Вы можете часто видеть альтернативное предложение return (src[0] << 24) + (src[1] << 16) + (src[2] << 8) + src[3];, которое вызывает неопределенное поведение, если src[0] >= 128 из-за переполнения целого числа со знаком, из-за неудачного правила, согласно которому целочисленные рекламные акции переводят uint8_t в подписанное int. А также вызывает неопределенное поведение в системе с 16-битным int из-за больших сдвигов.

Современные компиляторы должны быть достаточно умными, чтобы оптимизировать это, например сборка, созданная clang little-endian:

read_be32:                              # @read_be32
    mov     eax, dword ptr [rdi]
    bswap   eax
    ret

Однако я вижу, что gcc 10.1 создает гораздо более сложный код, это кажется неожиданной ошибкой оптимизации, которая упускается из виду.

Это решение не полагается на доступ к неактивным членам объединения, но вместо этого полагается на операции сдвига битов целого числа без знака, которые могут переносимо и безопасно преобразовывать из прямого порядка байтов в обратный порядок байтов или наоборот

#include <stdint.h>

uint32_t convertEndian32(uint32_t in){
  return ((in&0xffu)<<24)|((in&0xff00u)<<8)|((in&0xff0000u)>>8)|((in&0xff000000u)>>24);
}

Этот код считывает uint32_t из указателя на uchar_t в хранилище с прямым порядком байтов, независимо от порядка байтов в вашей архитектуре. (Код действует так, как если бы он читал число с базой 256)

uint32_t read_bigend_int(uchar_t *p, int sz)
{
    uint32_t result = 0;
    while(sz--) {
        result <<= 8;   /* multiply by base */
        result |= *p++; /* and add the next digit */
    }
}

если вы позвоните, например:

int main()
{
    /* ... */
    uchar_t buff[1024];
    read(fd, buff, sizeof buff);

    uint32_t value = read_bigend_int(buff + offset, sizeof value);
    /* ... */
}