По-моему, он вообще не работает.

везде будет ENDIAN_LITTLE. Потому что а) это препроцессор и он работает независимо от платформы, б) операция >> для целочисленных типов так же не зависит от платформы.

не зависит от платформы - всмысле ведет себя как little endian?

> не зависит от платформы - всмысле ведет себя как little endian?

Ты правда считаешь, что результат операции сдвига одного и того же числа на одно и то же число разрядов зависит от endianness?

Скажи, а результат выражения 128*2 - тоже? %)

Что значит 'как little endian'? Битовые операции не привязаны к endian, привязаны к значимости битов.

Сори, туплю к утру. Вопрос закрыт %)

>int num = 1;

Лучше intmax_t, наверное. Во всяком случае запрета равный размер char и int не припоминю.

Там где int == char уже пофигу биг или литлендиан.

>Там где int == char уже пофигу биг или литлендиан.

Почему? Для long или long long могут быть нюансы.

Так вы озвучте архитектуру и ньюансы чем вату катать :)

> Там где int == char уже пофигу биг или литлендиан.

Ненене. Представь, что char - 32 бита %)

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

> Это ничего не меняет

Работал на таких машинах? Я - да, и кое-что меняется.

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

Big или little прежде всего имеет значение для обмена с внешним миром.

>Big или little прежде всего имеет значение для обмена с внешним миром.

Внешний мир и конкретный процессор это не одно и тоже - используй сериализацию.

> Внешний мир и конкретный процессор это не одно и тоже - используй сериализацию.

Кхм. А для чего еще знать endianness, как не для (де)сериализации?

По-твоему, сериализация не бывает бинарной?

>А для чего еще знать endianness, как не для (де)сериализации?

Ты вроде говорил что-то про то что работал на каких-то архитектурах где char == 32 бит - это был какой процессор - be или le ?

LE

>LE

А с чего он так решил ? :) Какая разрядность у него была ? У него были инструкции которые интерпретировали длинные целые или вещественные именно как LE или твое ПО эти данные так интерпретировало ? Если твое ПО то как я и говорил в таком случае пофиг be или le этот процессор.

>> LE

А с чего он так решил ? :)

Он ничего не решал, он просто был LE. Я это видел.

Какая разрядность у него была ?

Это сложный вопрос. Я склоняюсь к мнению, что 32.

У него были инструкции [...]

Нерелевантно.

>Нерелевантно.

Понятно что ты не понимаешь нифига :)

> Понятно что ты не понимаешь нифига :)

Просто ты не способен оценить глубину моего понимания.

>Ты вроде говорил что-то про то что работал на каких-то архитектурах где char == 32 бит - это был какой процессор - be или le ?

Размер char связан не только с особенностями архитектуры, но и конкретной реализацией компилятора. Если мне не изменяет память, по стандарту C99 тип char - это тип, в котором можно представить базовый набор символов. На x86_32/x86_64 компилятор может использовать 32-битовый char.

http://svn.boost.org/svn/boost/trunk/boost/detail/endian.hpp

>Размер char связан не только с особенностями архитектуры, но и конкретной реализацией компилятора.

Пиздешь - char это байт, а вот байт может быть и не 8 бит но зависит это от архитектуры.

char это не байт, читай стандарт.

Какой толстенький - а сколько это по стандарту ?
The sizeof operator yields the size (in bytes) of its operand
в то время как всегда sizeof(char) == 1

>char это байт

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

Это уже проблемы компилятора, каким образом он абстрактную модель С99 переведет в машинный код. Например, 9-битовые C99-байты на x86_32/x86_64.

>Например, 9-битовые C99-байты на x86_32/x86_64.

Не - ты лучше пример с кодом приведи где будет 9 бит и sizeof.

Читать что ли не умеешь? По стандарту sizeof char == CHAR_BIT, а это number of bits for smallest object that is not a bit-field (byte) и должно быть не меньше 8.

>Не - ты лучше пример с кодом приведи где будет 9 бит и sizeof.

На счет 9 не знаю, но я кодил девайс с sizeof char == 16.

В смысле CHAR_BIT == 16, sizeof char соответственно 2.

Не - ты лучше пример с кодом приведи где будет 9 бит и sizeof.

Любой корректный С99 код должен нормально работать с 9-битовым байтом. Теории ради:

#include <stdint.h>
int main(void) {
    char a;
    char b[2];

    printf("%d %d %d\n", CHAR_BIT, sizeof(a), sizeof(b)); // 9 1 2
    
    return 0;
}

Блин, вру, sizeof char всегда 1, а вот CHAR_BIT может быть разным. И sizeof возвращает соответственно длину не в байтах по 8 бит, а в блоках по CHAR_BIT.

>Теории ради:

Имеется в виду, что для компилятора, реализующего 9-битовые байты, это самый обычный код.

>В смысле CHAR_BIT == 16, sizeof char соответственно 2.

А ты уверен что sizeof(char) == 2 в c99 ? Если это так то это не соотвествует стандарту и пофигу на какой архитектуре это было и не надо песен про CHAT_BIT.

>Любой корректный С99 код должен нормально работать с 9-битовым байтом. Теории ради:

Вообщето я просил тебя привести пример кода на x86 про которые ты говорил что сможешь char использовать любой длины, а у тебя sizeof(b) == 2 это либо дос либо не x86 либо никакой не стандартный компилятор.

Все правильно, массив же.

Ну да - это я тупанул, только все равно не верю что будет так на х86

// 9 1 2

> И sizeof возвращает соответственно длину не в байтах по 8 бит, а в блоках по CHAR_BIT.

sizeof всегда возвращает длину в байтах. Байт не обязательно имеет размер 8 бит.

Хватит нести охинеию

Внезапно

http://lmgtfy.com/?q=gcc+detect+endianness

Я под байтам понимал 8-битный байт. Просто все так привыкли к этому, что чтобы не создавать путаницы я разделил понятия байта (8-битного блока) и просто блока.

В принципе, согласен с тобой.