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

RxTx (25.07.2020 10:11, просмотров: 620) ответил fk0 на На счёт memcpy: с одной стороны да, ты можешь подсунуть невыравненный адрес и всё должно работать. И действительно, если ты руками там как-то аллоцировал память, посчитал адрес, он оказался невыравненный -- всё будет работать. Будет вызвана "неоптимальная" версия memcpy. А в случае с гудвиновским багом компилятор был обманут: ему сказали, что будеут копировать вот такой-то тип, а этот тип никак не может лежать на невыравненном адресе, следовательно, компилятор знает, если

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

работе компиляторов. То есть пойти дальше. У тебя явно есть время и тебе не лениво сопровождать это еще и фрагментами C++ кода. За такую пассионарность тебя по-идее надо благодарить. Но сейчас для меня увы, не то время, и мне хотелось бы просто чёткого однозначного вердикта, в этом моя цель. Итак, лично я считаю что ситуация Гудвина это баг (компилятора/оптимизатора + окружения) и так быть не должно. Вопрос к тебе. Как считаешь ты - это баг или нет? Ответь коротко и однозначно.

Ответить

- Нет, это не баг. Потому, что это UB. Потому, что изначально взяли указатель на int и присвоили ему что-то, что не является указателем на int (об чём есть строчка в стандарте). Далее уже не важно. Более того, ещё раз повторю, в рамках СТАНДАРТНОГО C/C++, возникновение такого "не бага" -- в принципе невозможно. Оно появляется из-за "бажной" реализации упакованных структур. Ты прицепился к memcpy и считаешь, что мол баг. Но класс проблем же НАМНОГО ШИРЕ, чем только memcpy. fk0(858 знак., 25.07.2020 16:40)
  - Вчера я прочитал что ты написал и планировал самостоятельно поэкспериментировать. Слова это одно, а когда начинаешь разбираться сам легко может быть другое. Не вышло, нет времени, поэтому все что я здесь пишу основано на исходных данных этой темы. Кстати беглое изучение документации на тему 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)

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