caxapa.ru :: Опять за рыбу деньги. Расширение в виде #pragma pack в GCC есть? Есть. memcpy в GCC есть? Есть. Где-нибудь в доке GCC написано, что к элементам пакованной структуры применять memcpy нельзя? Нигде. Бага GCC очевидна. Чего спорить-то? Хоть бы warning выдавал, как тот же IAR делает (Used the address of unaligned structure member).

LightElf (26.07.2020 15:08, просмотров: 557) ответил fk0 на UB значит, что возможное дальнейшее развитие сценария писателями компиляторов не рассматривается. Такого мол изначально не может быть, программист не допустит. Поэтому если при анализе ситуации возникает UB, то нет смысл думать что если то, или если это -- оно в принципе невозможно в корректной программе. Выражение "&IH.conag" само по себе UB. Поэтому заявить, что мол в компиляторе баг и притягивать дальнейшие преобразования типа и вызов memcpy не нужно: в корректной

Опять за рыбу деньги. Расширение в виде #pragma pack в GCC есть? Есть. memcpy в GCC есть? Есть. Где-нибудь в доке GCC написано, что к элементам пакованной структуры применять memcpy нельзя? Нигде. Бага GCC очевидна. Чего спорить-то? Хоть бы warning выдавал, как тот же IAR делает (Used the address of unaligned structure member).

Не надо делать мне как лучше, оставьте мне как хорошо

Ответить

- Именно в gcc бага нет, как и в clang последних версий. Они применяют атрибут меняющий alignof на 1 автоматически. И там получаются инструкции ldrb при обращении и медленная версия memcpy. Но ты _доказать_ что это баг в keil или ранних версиях clang -- не сможешь. Баг в чём? Я выше привёл доказательство, что это UB, a следовательно не баг. - fk0(26.07.2020 15:27)
  - Если компилятор рассматривает void* как int*, то это его обязанность убедиться в допустимости такой замены в каждом конкретном вызове. - LightElf(26.07.2020 15:39)
    - Так для типа int -- всё корректно. Некорректно для того типа, что лежит в упакованной структуре. Это не int, потому, что int не может лежать на невыравненном адресе. Это другой тип. Но в структуре записано что int, что и приводит к краху. - fk0(26.07.2020 15:43)
      - Компилятор знает, что в общем случае void* нельзя приводить к int*. Компилятор либо знает, что тип лежит в упакованной структуре и должен генерировать правильный код. Либо компилятор не знает, где лежит данный конкретный int и тогда должен исходить из худшего (раз уж он поддерживает такие конструкции). А вот это "здесь читаем, здесь не читаем, а здесь - рыбу заворачивали" есть косяк и бага. - LightElf(26.07.2020 16:22)
        
        Косяк и бага в том, что обычный тип int никак не может лежать в упакованной структуре. Потому, что int не может лежать по невыравненному адресу. С чем ты не согласен? - fk0(26.07.2020 16:26)
        
        Блин. Компилятор поддерживает #pragma pack(). Значит утверждение "int не может лежать по невыровненному адресу" - для этого компилятора ложно. Или трусы, или крестик. Или компилятор поддерживает некую фичу и она работает как положено, или не поддерживает. А вот это вот: "мы поддерживаем-поддерживаем, но все никак не держится" - детский сад, штаны на лямках. - LightElf(26.07.2020 23:47)
        
        Ничего не значит. Int -- это конкретный тип данных, на 32-битном арме с атрибутами sizeof(int) == 4 и alignof(int) == 4. А ты хочешь тип с атрибутом aligof(type) == 1. Не может один тип данных проявлять квантовую запутанность и иметь одновременно два значения alignof! Значит это не int, это, условно, unaligned_int. А если это другой тип, это порождает массу сложностей сразу, бьющих преимущественно по программисту, хотя наверное так сделать можно. А если запутанность и fk0(735 знак., 27.07.2020 00:01)
        
        Да тнб ради, пусть он будет unaligned int и пусть он не будет совместим по указателю. Пусть ошибку при компиляции выдает или предупреждение хотя бы. Но не компилить втихую бажный код с понтом так и надо. - LightElf(27.07.2020 00:39)
      - SciFi же дал ссылку на кейловскую документацию: Taking the address of a field in a #pragma packed struct does not yield a __packed pointer. Так что это не баг, а фичер: в структуре лежит __packed int, а берёшь адрес, и брюки превращаются... превращаются брюки... Идиотизм конечно, но bug report слать действительно бесполезно. - йцyкeн(26.07.2020 15:58, ссылка)
        
        Тут тонкость в том, что проблема будет только лишь при разыменовании указателя. Для memcpy() тут исключение. memcpy() принимающая void* всегда должна работать корректно при любом значении указателя, выравнен он или не выравнен. Однако в-том то и дело, что в данном случае без "ручного вмешательства" правильно она не работает. - RxTx(26.07.2020 16:24)
        
        В ИАРе как раз "ручное вмешательство" нужно, чтобы получить хардфолт. Функции memcpy() в ИАРе на самом деле нет, компилятор подставляет __aeabi_memcpy или __aeabi_memcpy4. __aeabi_memcpy4 не проверяет выравнивание, считается, что компилятор не промахнётся, и ИАР не промахивается. Какого чёрта Кейл работает по-другому - для меня загадка. - йцyкeн(26.07.2020 17:01)
        
        Угу. Понятно. - RxTx(26.07.2020 17:08)
        
        Натыкался в этих ваших тырнетах на список весьма доставляющих примеров undefined behavior. Там срывали покровы и открывали глаза. Советую погуглить на эту тему, можете после этого изменить мнение по поводу того, что кому чего должен и почему. - SciFi(26.07.2020 16:27)
        
        Проблема же уже есть и не при разыменовании указателя, а ещё на этапе компиляции, когда подставилась не та версия memcpy. Расчитанная на честный int. - fk0(26.07.2020 16:27)
        
        Вот именно это ты и путаешь. Тебе стоит понять, что "еще на этапе компиляции" в C++ это одно. Потому что "еще на этапе компиляции" для инстанциации шаблонов это работает компилятор (и к нему применим стандарт). А в данном случае то что ты ложно считаешь "еще на этапе компиляции" было не при работе компилятора. СИ компилер уже отработал. Это случилось в backend. На фазе кодогенерации/подстановки оптимизированных инстансов memcpy. - RxTx(26.07.2020 16:55)
        
        Какая разница. Проблема налицо -- не соответствие типов. Уже написали 10 раз как её вылечить, через __packed применимое к члену структуры. Но в целом это тоже костыль, ибо нарваться можно ещё неизвестно где. Я бы просто не использовал упакованные структуры от греха подальше. Кроме может быть, очень тривиальных случаев и где это даёт существенный профит в скорости, объёме памяти и т.п. - fk0(26.07.2020 17:20)
        
        Я тебя услышал и понял. Спасибо за приятную беседу. - RxTx(26.07.2020 17:45)

Микроконтроллеры