caxapa.ru :: Никак по-разному разложиться не может. Разложится всегда именно так же как и с прагмами. Потому, что иначе не были бы возможны массивы (alignas == sizeof) если речь идет о типах uint8, uint16, uint32 и о "ручном" раскладывании с выравниванием, как сделано у тебя. А если речь о других типах (структуры), или раскладка не выровненная (int32 не на 32-битной границе), то возникает упомянутая мною проблема: невозможность использования указателей. Выводы -- прагмы бесполезны и не

fk0, легенда (08.04.2020 11:42, просмотров: 665) ответил LightElf на Но зачем делать руками работу компилятора и/или железа? Эндианность, очевидно, в IP пакете фиксирована. А в коде, очевидно, используются стандартные HTONL()/htonl() сотоварищи. Без прагм, в зависимости от компилятора и целевой платформы, может разложиться весьма по-разному. С прагмами - единственным определенным образом. И почему это "случайно выровненный int32"? Вполне себе не случайно, а вовсе даже прописано в спецификации на драйвер канального уровня. Для

Никак по-разному разложиться не может. Разложится всегда именно так же как и с прагмами. Потому, что иначе не были бы возможны массивы (alignas == sizeof) если речь идет о типах uint8, uint16, uint32 и о "ручном" раскладывании с выравниванием, как сделано у тебя. А если речь о других типах (структуры), или раскладка не выровненная (int32 не на 32-битной границе), то возникает упомянутая мною проблема: невозможность использования указателей. Выводы -- прагмы бесполезны и не

нужны в данном твоем случае. А в других случаях -- путь к бесконечным приключениям в неожиданных местах.

[ZX]

Ответить

- А ты упертый :) Но блох ты ловишь не там. Разложиться по-другому может, особенно на архитектурах без 16-битных операций (типа ARMv4) - компилятор выровняет uint16_t на 32 бита. А вот как раз получить раскладку с int32 не на 32-битной границе - это надо сильно постараться. Ну и использование указателей на поля структуры, вместо указателя на структуру целиком - это путь к успеху. - LightElf(08.04.2020 12:17)
  - Отлично. Но ты ж сам доказал, что говнокод. На ARMv4. У тебя там что лежит за 16-битным значением окажется не выровненным и на него нельзя будет взять указатель. А сериализация ручками -- она всегда работает, надежно железобетонно. И использование указателей на поля структуры -- нормальный способ, иначе как писать абстрактные функции, а не функции работающие именно с такой структурой. Хотя конечно скалярные значения нормальные люди возвращают вовсе по-значению, но случаи они fk0(14 знак., 08.04.2020 13:50)
    - Я ж говорю - упертый ты :) В приведенной выше упакованной структуре (стандартном заголовке IP пакета) все поля натурально выровнены. Т.е. uint16_t лежит по смещению, кратному двум, а uint32_t лежит по смещению, кратному четырем. Так задумано изначально не самыми глупыми людьми. Соответственно, если сама структура лежит по адресу кратному четырем, то и все ее поля лежат как положено. И указатели нормально можно брать и использовать. Упаковка нужна, чтобы особо умные LightElf(208 знак., 08.04.2020 16:21)
    - Ну есть же возможность объявить указатель __packed, тогда компилятор знает, что выравнивания нет. - VLLV(08.04.2020 14:55)
      - Покажи пальцем где есть, я не в курсе. Всю жизнь упакованными были только структуры, а не указатель на int. Кроме того, невозможно же всем функциям присвоить такой атрибут. Есть, например, обычная функция, которая возвращает значение по-указателю (например, time(3)) и она ни сном, ни духом, что её аргумент могут положить в упакованную структуру. - fk0(08.04.2020 15:09)
        
        Help IAR VLLV(1 знак., 08.04.2020 17:45, картинка)
        
        У меня ИАР ругается: argument of type "int __packed *" is incompatible with parameter of type "int *" йцyкeн(379 знак., 08.04.2020 15:55)
        
        А разве компилятор не пожалуется, если взять такой указатель без явного приведения типов и т.п. трюков? - AlexBi(08.04.2020 15:15)
        
        Невыровненный доступ компилятор может еще и догадается обыграть, а вот урезанное поле - уже не обязательно. Помню у меня запись в упакованную структуру грохала пару соседних полей. Решил отменой упаковки везде где можно. lloyd(47 знак., 08.04.2020 15:36)
        
        "Урезанное поле" - это когда пакед и не пакед структура различаются по размеру? И потом a=b, где а и b структуры с разной паковкой? Мне кажется пакед и не пакед компилятором считаются разными типами со всеми вытекающими ошибками на этапе компиляции. - AlexBi(08.04.2020 15:55)
        
        int:4 - я про такие. - lloyd(08.04.2020 16:00)
        
        Указатели на битовые поля невозможны. И сами битовы поля такой же источник граблей как упакованные структуры. Их давно пора выкинуть из стандарта, а упакованных структур и никогда не было в стандарте, к слову (по причине массы сопутствующих проблем и невозможности писать портируемый код). - fk0(08.04.2020 16:20)
        
        Битовые поля, как и обычные поля в структуре - это эффективный способ систематизации данных. Да, есть недостатки, но цель выполняет. Если дурак наступает на грабли, так что, от использования граблей отказаться? - VLLV(08.04.2020 18:06)
        
        Поэтому в каждом компиляторе есть свой собственный, уникальный способ сделать упакованные структуры. Я ж говорю, стандартизаторы - те еще затейники. Ввести в стандарт мало кому нужный complex.h, но не ввести стопку элементарных макросов с описанием целевой машины (типа эндианности, направления роста стека, нативного размера машинного слова и т.д.). В результате каждый второй Цэ-проект на гитхабе занимается попытками выяснить сие по косвенным признакам. - LightElf(08.04.2020 16:34)
        
        Смотря как смотреть. Упакованные структуры -- не нужны. Знать тебе эндианность, направление роста стека и прочее -- зачем? Если ты пишешь портируемый код, то ты не должен полагаться на такие знания. Это нужно только системным программистам в исключительных случаях. А пытаются применять когда попало, когда не нужно -- и огребают проблем. Код на другой платформе уже или не скомпилируется, или не зарабоатет. А complex.h же очевидно нужен в цифровой обработке сигналов, fk0(9 знак., 08.04.2020 16:55)
        
        Блин, но системное программирование - это и есть основная область применения Цэ в дивном новом мире питонов и джаваскриптов. И как раз для портируемости и надо знать эндианность и все такое прочее. Прятать голову в песок можно сколько угодно, но вот тебе IP-пакет и у него строго предопределенная эндианность. Ввели бы один раз в стандарт что-то вроде GCC-шного __BYTE_ORDER__ - и прекрасно. То же самое с упакованными структурами/типами. Если бы они не были нужны - никто бы LightElf(359 знак., 08.04.2020 18:29)
        
        Вот потому и в стандарт и не вводится. Написанная программа должна одинаково работать на всех платформах. Почему не стандартизовать -- я ответил, из-за проблемы с указателями на члены структуры. Касательно ЦОС, я видел, где complex.h использовался. Питон здеь ни при чём, можно конечно всё то же самое сделать руками, посчитав синусы и косинусы отдельно, и более того в реализации на целых числах так и будет, но в обобщённом коде -- вполне себе решение. И да, системные fk0(209 знак., 08.04.2020 22:17, ссылка)
        
        чётко сделал сериализатор. По крайней мере мне нравится - megajohn(24.07.2020 09:02)
        
        За ссыль на онлайн компилер - спасибо. Скомпилил твой сериализатор под MIPS и ARMv5. Байтораздирающее зрелище... - LightElf(09.04.2020 12:49)
        
        Простой вопрос: если пакованная структура представляет собой регистры некоторого периферийного блока, что делать будешь? - LightElf(09.04.2020 03:14)
        
        Ничего делать не буду, не нужно так делать. Это говнокод. Уже массу раз такое видел: наупаковывают, еще и с битовыми полями, и работает оно только в этой версии фирменного недокомпилятора. К регистрам нужно обращаться по адресу, и не нужны там недоструктуры отсутствующие в стандарте. Достаточно массы дефайнов. - fk0(09.04.2020 03:36)
        
        *Вздрогнул* Ужос... - LightElf(09.04.2020 12:45)
        
        Это типа такого? Andreas(478 знак., 09.04.2020 09:26)

Средства и методы разработки