йцyкeн (26.07.2020 15:58, просмотров: 521) ответил fk0 на Так для типа int -- всё корректно. Некорректно для того типа, что
лежит в упакованной структуре. Это не int, потому, что int не может
лежать на невыравненном адресе. Это другой тип. Но в структуре
записано что int, что и приводит к краху.-
- Тут тонкость в том, что проблема будет только лишь при
разыменовании указателя. Для 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)
- Какая разница. Проблема налицо -- не соответствие типов. Уже
написали 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)
- Тут тонкость в том, что проблема будет только лишь при
разыменовании указателя. Для memcpy() тут исключение. memcpy()
принимающая void* всегда должна работать корректно при любом
значении указателя, выравнен он или не выравнен. Однако в-том то и
дело, что в данном случае без "ручного вмешательства" правильно она
не работает. - RxTx(26.07.2020 16:24)