caxapa.ru :: Нет, это не баг. Потому, что это UB. Потому, что изначально взяли указатель на int и присвоили ему что-то, что не является указателем на int (об чём есть строчка в стандарте). Далее уже не важно. Более того, ещё раз повторю, в рамках СТАНДАРТНОГО C/C++, возникновение такого "не бага" -- в принципе невозможно. Оно появляется из-за "бажной" реализации упакованных структур. Ты прицепился к memcpy и считаешь, что мол баг. Но класс проблем же НАМНОГО ШИРЕ, чем только memcpy.

fk0, легенда (25.07.2020 16:40, просмотров: 702) ответил RxTx на Опыт жизни и общефилософское наблюдение показывают: дискуссия (разговор, беседа) только тогда здрава, заканчивается познавательно и позитивно, когда ее участники имеют одну и ту же цель и заинтересованы в одном и том же результате. Моя цель в данном случае - выяснить четкую практическую истину. Где что сломалось, почему, кто виноват и что делать. Твоя цель явно в том чтобы либо образовать меня/нас, либо просто изложить (насколько ты понимаешь и способен) свои представления о

Нет, это не баг. Потому, что это UB. Потому, что изначально взяли указатель на int и присвоили ему что-то, что не является указателем на int (об чём есть строчка в стандарте). Далее уже не важно. Более того, ещё раз повторю, в рамках СТАНДАРТНОГО C/C++, возникновение такого "не бага" -- в принципе невозможно. Оно появляется из-за "бажной" реализации упакованных структур. Ты прицепился к memcpy и считаешь, что мол баг. Но класс проблем же НАМНОГО ШИРЕ, чем только memcpy.

"Баг" проявляться будет при любом взятии указателя или ссылки (неявно, для массивов) на члены упакованной структуры.

Для тех кто недопонял: проблема уже в выражении "&IH.conag", что снаружи (memcpy, что угодно, приведения к void*...) -- уже не важно. В этом выражении результатом является тип "указатель на int", и результату присваивается адрес поля conag который не является валидным указателем на int (потому, что указатель на int не может быть не выравненным). Стандарт утверждает, что:

ISO/IEC 9899:201x, разделе 6.3.2.3 Pointers, параграф 7

A pointer to an object type may be converted to a pointer to a different object type. If the

resulting pointer is not correctly aligned for the referenced type, the behavior is

undefined.

Результирующий указатель, который получается в результате вычисления "&IH.conag", не correctly aligned. Дальше не расти трава.

[ZX]

Ответить

- Вчера я прочитал что ты написал и планировал самостоятельно поэкспериментировать. Слова это одно, а когда начинаешь разбираться сам легко может быть другое. Не вышло, нет времени, поэтому все что я здесь пишу основано на исходных данных этой темы. Кстати беглое изучение документации на тему memcpy показывает что существует большое пространство для маневра не только с тривиальными ключами компилятора, прагмами и атрибутами но и что важно, с подключаемыми либами/выбором obj RxTx(5329 знак., 26.07.2020 12:46)
  - UB значит, что возможное дальнейшее развитие сценария писателями компиляторов не рассматривается. Такого мол изначально не может быть, программист не допустит. Поэтому если при анализе ситуации возникает UB, то нет смысл думать что если то, или если это -- оно в принципе невозможно в корректной программе. Выражение "&IH.conag" само по себе UB. Поэтому заявить, что мол в компиляторе баг и притягивать дальнейшие преобразования типа и вызов memcpy не нужно: в корректной fk0(4348 знак., 26.07.2020 13:47)
- Вы заблудились в сферических абстрацкиях в ваккуме (возможно вместе с компиляторописателями). В данном случае мы работаем на процессоре M3 который УМЕЕТ делать unaligned access. Поэтому если компилятор знает что генерит код для M3 то никакого undefined behavior при невыровненном указателе на ЭТОЙ архитектуре нет - корректное исполнение обеспечит hardware. - 3m(26.07.2020 11:42)

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