конечно. И это обязательно надо учитывать, когда преобразуешь байтовый массив к многобайтным типам на другой архитектуре. Собственно. это тоже самое, как обозначить тип переменной просто int . а потом удивляться. что ее представление разное на АВР и СТМ Но байтовый массив-то будет тот же самый. Я не пойму, почему такой простой аргумент, как пример графических и музыкальных файлов не действует на ТС. Или он думает. что в формате МП3 байты заранее выровнены под все возможные архитектуры в мире? )
Для этого есть функции 'hton*' и 'ntoh*', которые расшифровыватся как Host_TO_Network и Network_TO_Host. В частности htons и ntohs для 16-тибитных чисел и htonl и ntohl -- для 32-ухбитных. Для 64-ёхбитных -- be64toh и htobe64 -- BigEndian_TO_Host и Host_TO_BigEndian (в сети принято использовать big endian). Эти функции придуманы для того, что бы корректно обрабатывать сетевые данные на разных системах. В системах, которые используют BE (big endian), функции ни чего преобразовывать не будут. В системах, которые используют LE (little endian), данные будут преобразованы соответствующим образом. Эти функции позволяют унифицировать код для разных платформ -- BE и LE.
Успел таки книги почитать. А по нормальному никак... обратное хранение битов в байте это не инверсия? Про музыку молчу... она не образная структура в массиве, как и формат BMP. Почитайте... я это делал на разных платформах. Вот: https://moxa.ru/forum/index.php?/topic/25208-uc-7112-lx-plus-может-баловство-а-может-и-нет/ Зубы значит заговариваем! Вообще-то сегодня пятница Точнее уже суббота... но в магазин более не судьба... поздно Наверное думаете, что другие должны подпрыгнуть, в прыжке свистнуть и по приземлении начать пердеть в пузырёк, показывая дулю воробьям