caxapa.ru :: Я выше сказал, что проблема возникает не в memcpy, а в выражении &IH.conag. Что там после -- уже не важно. Результат данного выражения не валиден. Он содержит корректное числовое значение, но некорректный тип, из-за чего оптимизатор принимает не верное решение.

fk0, легенда (26.07.2020 15:39, просмотров: 465) ответил LightElf на Я привязался к memcpy ровно потому, что ее параметры прямо декларируются как void*. void* означает, что указатель может быть любым. И компилятор обязан этот факт учитывать. Тяготы и лишения компиляторописателей меня интересуют постольку-поскольку.

Я выше сказал, что проблема возникает не в memcpy, а в выражении &IH.conag. Что там после -- уже не важно. Результат данного выражения не валиден. Он содержит корректное числовое значение, но некорректный тип, из-за чего оптимизатор принимает не верное решение.

[ZX]

Ответить

- Блин. Писатели GCC сами добавили в свой компилятор поддержку упакованых структур. И не осилили ее корректно реализовать (в отличие от других компиляторов). А ты пытаешься убедить всех, что это не баг, а фича. - LightElf(26.07.2020 15:46)
  - Вот именно в этом я и пытаюсь убедить -- что сами упакованные структуры нихрена не продуманная "фича", страдающая множественными дефектами и не совместимостью со стандартным языком C/C++. Поэтому её нет в стандарте. Потому, что куда не ткнись, любое нетривиальное использование (кроме непосредственного обращения к членам как к значениям) -- неопределённое поведение. А как код-то писать? Шаг влево-вправо -- "баги". - fk0(26.07.2020 16:02)
    - А я тебе и говорю, что неопределенное поведение упакованных структур - это изначально косяк стандартизаторов языка. Эта фича есть во всех вменяемых компиляторах с лохматых времен. Наверно она нужна зачем-то. И все ее как-то реализуют. Но пуристы в комитете предпочитают прятать голову в песок и изобретают всякую никому не нужную хрень, вместо введения упакованных структур в стандарт. С описанием их конкретного поведения в разных случаях. Например, можно указать что адрес члена LightElf(139 знак., 26.07.2020 18:00)
      - В основе языка C лежит ЯВУ (B)CPL к которому добавлены системные возможности. Структуры (record, записи) в ЯВУ могут быть представлены неупорядоченными множествами. Для несистемного языка этого вполне достаточно. В С структуры появились не сразу, первые версии были без структур и Ричи сразу планировал прямое соответствие описания структур фактическому бинарному (битовому) расположению в памяти. К тому же первые версии C создавались для CISC машин, поэтому в оригинале RxTx(1382 знак., 29.07.2020 14:43)
        
        Как быть с множественным наследованием и таблицами виртуальный функций? Тебя зациклило на низкоуровневом программировании. - fk0(29.07.2020 17:39)
      - Косяк стандартизаторов в том, что этой недофичи попросту нет в стандарте? Оригинально. Её и не хотят принимать, потому, что очень много спорных моментов возникает. Значит компилятор должен уметь генерировать код умеющийся обращаться к невыравненным данным вообще (сейчас такой обязанности у компилятора нет). Значит объявление такой структуры должно автоматически вводит множество типов унаследованных от базовых (типа int), но со своим выравниванием. Значит эти типы должны fk0(375 знак., 26.07.2020 18:06)
        
        Все эти спорные моменты уже давно решены и реализованы. Так или иначе. Почему бы просто не стандартизовать ежу существующее поведение? - LightElf(26.07.2020 18:10)
        
        А где задокументировано, как они решены и реализованы? Если нигде, то что тогда стандартизировать? Я что-то не уверен, что всё прямо так решено: в начале топика я давал ссылку -- смотри, оно упакованный тип от неупакованного в упор не отличает. Легко это превратить в баг. И присваивание указателей, значит, проканает без ошибок. fk0(248 знак., 26.07.2020 22:19, ссылка, ссылка)
        
        ну смотри, проблема такая (паддинг, упакованные типы) существует? существует. другие проблемы связанные с физической реализацией работы с конкретными типами существуют? существуют. (переполнения там, арифметика с насыщением). так почему бы хоть какое-то общее множество не внести в стандарт? слишком уж далеко виртуальная абстрактная машина стала абстрагироваться от существующей физической реализации АЛУ в процессорах. - Mahagam(29.07.2020 15:28)
        
        Потому, что весь топик об этом. Чтоб внести в стандарт упакованные структуры -- нужно вообще ввести новые типы данных не совместимые с существующими (с чего баг начался). - fk0(29.07.2020 17:41)
        
        а может хватило бы модификатора? по типу volatile. который не меняет тип, но меняет работу с ним. Mahagam(130 знак., 30.07.2020 01:15)

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