Как вещь мне в кейле не нравится(может быть единственная) этот самый формат. Приходит ко мне пакет где данные лежат INTEL формате т.е. 1й байт младший и читаю я из этого пакета в переменную типа ulong вот таки некрасивым способом:

ULONG(ltemp).b[3]=rxbuf[0];
ULONG(ltemp).b[2]=rxbuf[1];
ULONG(ltemp).b[1]=rxbuf[2];
ULONG(ltemp).b[0]=rxbuf[3];

макрос:
//-----------------------------------------------------
// Type for treating 4 byte variables with byte by byte
//-----------------------------------------------------
typedef union _un_long {
unsigned long dw;
unsigned char b[4];
}un_long;

#define ULONG(x) (*((un_long*)&x))
У кого есть другие способы решения этой проблемы поделитесь пожлста

Под GCC есть макросы для переворота байтов, определtны в заголовке byteswap.h

я поступал еще некрасивее:
unsigned long lOutWord _at_ 0x20;
unsigned char cOutWord0 _at_ 0x23;
unsigned char cOutWord1 _at_ 0x22;
unsigned char cOutWord2 _at_ 0x21;
unsigned char cOutWord3 _at_ 0x20;
и получал от кейла четыре ругательства<img>

Сдвиги на 0,8,16,24 компилятор должен прооптимизировать в присваивания.

Ну это неправильно - в нормальных протоколах данные в машинозависимых форматах ходить не должны :-).
Ну а для разворота - классика жанра htons() "Host to Network Short" и htonl() "Host to Network Long" может существовать в поставке, как минимум реализован в виде макросов:

В этом есть какой-то скрытый смысл. Я натыкался на объяснение, счел его разумным, и потом сразу забыл ! Но пользуюсь вегда стадартными сдвигами и встроенными функциями типа _irol()_, _iror()_ и никогда не имел проблем. Вообще, в машинно-зависимые свойства компиляторов лучше не лезть.


Кстати да! Он великолепно оптимизирует!

а на 7 оптимизирует в 7 сдвигов всех 32-х разрядов<img> и приходится вручную переставлять байты и сдвигать только один раз