[mdmitry 0]

Самому определять это понятно, а в компиляторе такой информации нет?

Есть. Для GCC есть предопределенные макро, например, для arm-none-eabi-gcc (arm-none-eabi-g++)

#define __ORDER_LITTLE_ENDIAN__ 1234
#define __ORDER_BIG_ENDIAN__ 4321
#define __ORDER_PDP_ENDIAN__ 3412
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__

 

[DmitryM 0]

Самому определять это понятно, а в компиляторе такой информации нет?

 

The common predefined macros are GNU C extensions. They are available with the same meanings regardless of the machine or operating system on which you are using GNU C or GNU Fortran. Their names all start with double underscores

 

__BYTE_ORDER__

__ORDER_LITTLE_ENDIAN__

__ORDER_BIG_ENDIAN__

__ORDER_PDP_ENDIAN__

__BYTE_ORDER__ is defined to one of the values __ORDER_LITTLE_ENDIAN__, __ORDER_BIG_ENDIAN__, or __ORDER_PDP_ENDIAN__ to reflect the layout of multi-byte and multi-word quantities in memory. If __BYTE_ORDER__ is equal to __ORDER_LITTLE_ENDIAN__ or __ORDER_BIG_ENDIAN__, then multi-byte and multi-word quantities are laid out identically: the byte (word) at the lowest address is the least significant or most significant byte (word) of the quantity, respectively. If __BYTE_ORDER__ is equal to __ORDER_PDP_ENDIAN__, then bytes in 16-bit words are laid out in a little-endian fashion, whereas the 16-bit subwords of a 32-bit quantity are laid out in big-endian fashion.

You should use these macros for testing like this:

 

/* Test for a little-endian machine */

#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__

Common-Predefined-Macros.html

 

 

 

[Oleg_IT 0]

Спасибо

[Oleg_IT 0]

Я вас сходу по флажкам не понял. Переделал, работает.

Поторопился я радоватся, что битовый массив, что

#define FLAG_1     1

........................
Flags |= (1 << FLAG_1);

одно и тоже.

[Dron_Gus 2]

http://www.opennet.ru/man.shtml?topic=hton...3&russian=0

http://repo-genesis3.cbi.utsa.edu/crossref...tinet/in.h.html

 

 

[Oleg_IT 0]

http://www.opennet.ru/man.shtml?topic=hton...3&russian=0

http://repo-genesis3.cbi.utsa.edu/crossref...tinet/in.h.html

Интересно. Спасибо за ссылочки.

[alx2 0]

Поторопился я радоватся, что битовый массив,

Что такое "битовый массив"?

 

что

#define FLAG_1     1

........................
Flags |= (1 << FLAG_1);

одно и тоже.

Что "одно и то же"? Опишите подробнее, что, как Вам кажется, неправильно с приведенным вариантом.

Например, если у Вас в переменной Flags лежат флаги TCP, то приведенный Вами код установит флаг SYN. И этот код (в отличие от битовых полей в объединении) уже не зависит от реализации компилятора...

Изменено 17 октября, 2013 пользователем alx2

[Oleg_IT 0]

Что такое "битовый массив"?

Ошибся, битовое поле.

 

Что "одно и то же"? Опишите подробнее, что, как Вам кажется, неправильно с приведенным вариантом.

Например, если у Вас в переменной Flags лежат флаги TCP, то приведенный Вами код установит флаг SYN. И этот код (в отличие от битовых полей в объединении) уже не зависит от реализации компилятора...

Если я битовом поле

   union {
        struct {
            uint16_t FIN        : 1;    // No more data from sender
            uint16_t SYN        : 1;    // Synchronize sequence numbers
            uint16_t RST        : 1;    // Reset the connection
            uint16_t PSH        : 1;    // Push Function
            uint16_t ACK        : 1;    // Acknowledgment field significant
            uint16_t URG        : 1;    // Urgent Pointer field significant
            uint16_t Res1       : 6;    //: 4;    // Reserved - 0
            uint16_t DOff       : 4;    // Data Offset - 5
        };
        uint16_t L1;
    };

бит SYN, первый бит, ставлю в 1, то это будет тоже сомое, что

L1 |= (1 << 1)

Проверено.

[Golikov 0]

Проверено.

 

и что?

ну значит ваш компилятор переворачивает битовые поля в другой порядок.

Смысл то как раз избавить от этого и всю структуру битовых полей выкинут нафиг, заменить ее обычным 16 битным числом, куда честно ставить флаги, на те места где они должны быть, однозначно, независимо от компилятора...

Изменено 17 октября, 2013 пользователем IgorKossak
избыточное цитирование

[Oleg_IT 0]

Так ни битовые поля, ни работа с флагами задачу не решают. Функции по ссылке http://www.opennet.ru/man.shtml?topic=hton...3&russian=0 только помогут, они специально для этого сделаны.

[Golikov 0]

что - то я видать не понимаю.

 

Я утверждаю что во всех сетях нашей планеты флаг сигнала SYN стоит в одном и том же месте 16 битного поля размера и флагов. Не зависимо от того на каком процессоре и каким компилятором сделана программа. Значит всегда можно сделать константу равную 1 в этом месте, и иметь четко определенный флаг в нужном месте на любой системе.

 

Что не так то?

[Oleg_IT 0]

По факту получается не так, и порядок байт и порядок бит разный. А ставить эти биты так или иначе не имеет значения ини будут на одном и том же места и это правильно и понятно.

 

Скорей всего мы друг друга недопонимаем:)

[Golikov 0]

да.

 

порядок байт в интернете биг ендиан.

порядок бит как у всех младший бит нулевой.

 

вашу структуру битовых полей перевернул компилятор от того вы считаете что порядок другой. Но взяв другой компилятор он может ее опять перевернуть, потому вам рекомендуют с этим не играть и сделать флаги а не битовые поля структуры.

 

порядок байт из за того что у вас АРМ наверняка Litle endian, и потому он тоже другой. Но сменив процессор на тот в котором Big, такие бывают... у вас опять все навернется от того вам советовали сделать дефайн...

[alx2 0]

Так ни битовые поля, ни работа с флагами задачу не решают.

Вы по-моему не понимаете, что имеете дело с двумя разными проблемами:

1. Проблема порядка байт с ловах (Big/Little endianness). Она решается использованием стандартных функций htonl/ntohl/htons/ntohs.

2. Проблема порядка расплоложения битовых полей в структуре/объединении. Она решается отказом от использования битовых полей в данном случае.

Я говорил исключительно о второй проблеме. И обратил Ваше внимание на то, что код Flags |= TCP_FLAG_SYN; переносим, а код Flags.SYN = 1; - нет, так как порядок следования битовых полей может быть разным в разных компиляторах.

порядок байт из за того что у вас АРМ наверняка Litle endian, и потому он тоже другой. Но сменив процессор на тот в котором Big, такие бывают... у вас опять все навернется от того вам советовали сделать дефайн...

Вот поэтому и надо по возможности использовать htnl/nthl для преборазования из формата слов. Если хост little-endian, эти функции будут менять порядок байт в слове. Если хост big-endian - вернут свой аргумент в неизменном виде. Тогда при смене хоста ничего не навернется...

Изменено 18 октября, 2013 пользователем alx2

[Oleg_IT 0]

Кажется начинаю понимать обстановку. Без дефайнов не обойтись. Но всё равно не понятности остались, например в протоколе есть поле размером 13 бит, это байт и ещё немножко. Как в этом случае работает htnl/nthl?