Я считаю мы с тобой обменялись мнениями. Дальше пойдет уже
непринципиальное, и смысла обсуждать мелочи не вижу. Ты видимо
по-инерции, все еще не осознав или невнимательно, невдумчиво
прочитав мой пост, прибегнул к обсуждению стандарта C. Напрасно,
так как твои посты я перечитывал несколько раз, обдумывал, и даже
заметил что самое первое что ты написал в эту тему - это именно то,
что memcpy должна работать без всяких проблем! А потом у тебя
что-то сломалось :) Так вот, вычитай внимательно и осознай - обсуждать строчки стандарта тут бессысленно. Это проблема не языка СИ и не стандарта. Эта проблема изолирована от языка C на уровне платформы, оптимизации, кодогенератора и по всей видимости, корректных настроек.
Если шутки ради завести баг в багтрекер компилятора, то первое что я бы лично сам спросил - какую memcpy вы применяете? Вот где её взяли, туда и идите.
UB на уровне языка тут нет!
Прямого Bug'а реализации компилера... нет!
Считаю что вкралось какое-то недопонимание/факап на уровне настроек ключей компилера/линкера при смене старшей версии компилера и SDK .
И вообще, никто кроме ТС эту проблему в железе не проверял, так что возможны сюпризы, вплоть до того что на самом деле все работает нормально :)
RxTx (26.07.2020 16:46, просмотров: 592) ответил fk0 на UB значит, что возможное дальнейшее развитие сценария писателями
компиляторов не рассматривается. Такого мол изначально не может
быть, программист не допустит. Поэтому если при анализе ситуации
возникает UB, то нет смысл думать что если то, или если это -- оно
в принципе невозможно в корректной программе. Выражение
"&IH.conag" само по себе UB. Поэтому заявить, что мол в
компиляторе баг и притягивать дальнейшие преобразования типа и
вызов memcpy не нужно: в корректной