RxTx (26.07.2020 16:24, просмотров: 518) ответил йцyкeн на SciFi же дал ссылку на кейловскую документацию: Taking the address of a field in a #pragma packed struct does
not yield a __packed pointer. Так что это не баг, а фичер: в структуре лежит __packed int, а
берёшь адрес, и брюки превращаются... превращаются брюки...
Идиотизм конечно, но bug report слать действительно бесполезно.-
- В ИАРе как раз "ручное вмешательство" нужно, чтобы получить
хардфолт. Функции 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)
- Какая разница. Проблема налицо -- не соответствие типов. Уже
написали 10 раз как её вылечить, через __packed применимое к члену
структуры. Но в целом это тоже костыль, ибо нарваться можно ещё
неизвестно где. Я бы просто не использовал упакованные структуры от
греха подальше. Кроме может быть, очень тривиальных случаев и где
это даёт существенный профит в скорости, объёме памяти и т.п. - fk0(26.07.2020 17:20)
- Вот именно это ты и путаешь. Тебе стоит понять, что "еще на этапе
компиляции" в C++ это одно. Потому что "еще на этапе компиляции"
для инстанциации шаблонов это работает компилятор (и к нему
применим стандарт). А в данном случае то что ты ложно считаешь "еще
на этапе компиляции" было не при работе компилятора. СИ компилер
уже отработал. Это случилось в backend. На фазе
кодогенерации/подстановки оптимизированных инстансов memcpy. - RxTx(26.07.2020 16:55)
- В ИАРе как раз "ручное вмешательство" нужно, чтобы получить
хардфолт. Функции memcpy() в ИАРе на самом деле нет, компилятор
подставляет __aeabi_memcpy или __aeabi_memcpy4. __aeabi_memcpy4 не
проверяет выравнивание, считается, что компилятор не промахнётся, и
ИАР не промахивается. Какого чёрта Кейл работает по-другому - для
меня загадка. - йцyкeн(26.07.2020 17:01)