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

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

Также имейте в виду, что порядок следования байтов может быть разным для разных типов: например, PDP-11 представляет собой 16-битную архитектуру с прямым порядком байтов, а 32-битные целые числа строятся из двух 16-битных значений с прямым порядком байтов, что в итоге приводит к смешанному порядку байтов. порядок байтов

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

Я вижу для вас три возможности:

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

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

• Также вы можете записать данные в файл, как вы предложили, а затем прочитать обратно. Просто напишите два символа (файл в двоичном режиме), переместите указатель файла в позицию 1 и прочитайте символ.

Я полагаю, что вопрос сводится к следующему: является ли порядок следования байтов значимой концепцией на этой платформе, то есть оказывает ли он заметное влияние на поведение программы?

Если это не так, то порядок следования байтов (т. е. порядок, в котором отдельные байты, составляющие 32-битное число, хранятся в памяти) — это просто деталь реализации, которую вы не можете обнаружить, но которая и не должна вас беспокоить.

Если порядок следования байтов оказывает заметное влияние на поведение определенного аспекта языка... что ж, тогда создайте тест, основанный на этом поведении. Вот некоторые примеры:

• Как работает система адресации на платформе? Если вы увеличиваете адрес на единицу, скольким битам это соответствует? Если ответ состоит из восьми битов и система позволяет вам читать с адресов, не кратных четырем, то вы можете переместить указатель вперед на один байт (через обход к intptr_t) и таким образом проверить порядок следования байтов. (Да, это поведение, определяемое реализацией, но то же самое относится и к использованию объединения для проверки порядка следования байтов, а также всей концепции порядка следования байтов в целом.) Однако если наименьшая адресуемая единица памяти составляет 32 байта, то вы можете t проверить порядок байтов таким образом.

• Есть ли на платформе 64-битный тип данных (long long)? Затем вы можете создать объединение long long и двух int и построить на его основе свой тест на порядок следования байтов.

Битовые поля структуры должны корректно работать на любой платформе, даже на этой:

union {
   int i;
   struct {
       int b1 : 8;
       int b2 : 8;
       int b3 : 8;
       int b4 : 8;
   } s;
} u;

u.i = 1;
if (u.s.b1 != 0)
   ....

Вопрос не предлагает достаточно информации, но с тем, что он предлагает, я бы сказал: невозможно.

htonl должно работать:

if(htonl(1)==1) {
   /* network order (big-endian) */
} else {
   /* little-endian */
}

(Я не вижу никаких причин не реализовывать htonl и друзей обычным образом, даже для этой надоедливой гипотетической системы — хотя я не уверен, насколько полезной они окажутся на практике.)

Вы можете сдвинуть рассматриваемую переменную и посмотреть, с какого конца сдвигается 1.

Если ваш код зависит от того, является ли архитектура BE или LE, тогда ваш код должен иметь безопасность и не компилироваться для неизвестной платформы. Некоторые #if ! defined(ARCH_IS_LE) && ! defined(ARCH_IS_BE) \ #error unknown architecture должны делать.