caxapa.ru :: И он работает с любым типом корректно. Пока ему голову не заморочили взятием указателя на выровненный тип в упакованной структуре. В каком-то смысле, это недоработка компилятора, но стандарт не нарушается.

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

И он работает с любым типом корректно. Пока ему голову не заморочили взятием указателя на выровненный тип в упакованной структуре. В каком-то смысле, это недоработка компилятора, но стандарт не нарушается.

Ответить

- Мы говорим о нестандартном (но весьма распространенном) расширении. Причем тут ссылки стандарт? - LightElf(26.07.2020 15:42)
  - ОК. С точки зрения работы расширения проблема налицо. Но fk0 принялся ругать говнокод и защищать компилятор. За что ему большое спасибо! Всё подробно разжевал, ссылки привёл. Тема была - супер!!! - Nikolay_Po(26.07.2020 15:47)
    - Он не компилятор защищает, а свое представление о прекрасном. Это давняя дискуссия, которая тут периодически обостряется. - LightElf(26.07.2020 15:47)
  - Тогда на что ссылаться? По стандарту всё ок. А по мнению LightElf не ок? Нужен какой-то формальный документ, который описывает поведение компилятора. - fk0(26.07.2020 15:44)
    - На документацию конкретного компилятора - LightElf(26.07.2020 15:48)
      - Где в документации описывается что должно происходить в случаях: fk0(232 знак., 26.07.2020 15:59)
        
        А знаешь почему не описывается? Сям (компилеру и стандарту) просто чхать, какая там структура. Осознай это. Упакованная, не упакованная - именно сишечке по барабану. Осознай: требования по default data alignment (вообще по типам, не только выравнивание, но и размер) оно существует только для конкретной CPU платформы, не у компилятора. И padding (выравнивание) структур делает не компилятор следующий стандарту C, а бэкенд, именно он отвечает за платформу, ее выравнивание, RxTx(223 знак., 26.07.2020 17:22)
        
        В пятый раз повторяю, компилятор знает и используют такое понятие как alignof/alignas для любого типа данных, у gcc есть расширение -- атрибут __attribute__((aligned(N))), по аналогии с typeof() есть __alignof __(type) (в голом C, без C++). В голом C на него можно нарваться через generics, через sizeof() тоже можно если постараться. Именно что платформо-независимый генератор кода уже всем этим оперирует. Отнюдь не бэкенд. - fk0(26.07.2020 17:23)
        
        Ты слишком поспешно тут сделал выводы насчет "уже всем этим оперирует". Предупрежу что абсолютно точно в коде работы с атрибутами я не разбирался (хотя по аналогии с кодом/проблемой ТС ничто не мешает, просто лень/занятость). Все что ты перечислил - "тонкие нити" информации, которые 11й компилер вытягивает из констант существующих в кодогенерящем/платформозависимом BackEnd'е. RxTx(822 знак., 26.07.2020 18:12)
        
        Смешались в кучу люди, кони... Причём здесь бэкенд вообще и зачем знать как он устроен, если в документации, в справочнике для программиста явно сказано как оперировать этими атрибутами? Оно программисту средствами языка доступно. На самом верхнем уровне. Следовательно компилятор такими атрибутами тоже оперирует. - fk0(26.07.2020 22:21)
        
        Логично, что implementation defined behaviour должен быть описан в документации конкретного implementation. Разве не так? - LightElf(26.07.2020 17:21)
        
        Логично! И где, ткните меня носом! - fk0(26.07.2020 17:24)
        
        Я ж говорю - баг! "A conforming implementation of ISO C is required to document its choice of behavior in each of the areas that are designated “implementation defined”." - LightElf(26.07.2020 18:02)
        
        Подразумевается areas из стандарта C, а не вообще всё реализованное компилятором. - fk0(26.07.2020 18:07)
        
        Большинство приличных компиляторов документируют свои расширения и их особенности. Вот что пишет IAR: LightElf(524 знак., 27.07.2020 00:03)
        
        А что будет при обмене "int *" и "packed int*" указателями/ссылками? Они не совместимы вообще? Это, то что я имею ввиду, когда говорю, мол сделать можно, но программисту программировать будет невозможно. - fk0(27.07.2020 00:05)
        
        Так уже обсуждали. Конечно, если передавать __packed int* функциям типа scanf, на некоторых архитектурах могут быть сюрпризы. Имхо, корень зла тут не в атрибуте __packed, а в функции с ... в списке параметров. - йцyкeн(27.07.2020 13:11, ссылка)
        
        Будет диагностика "Warning[Pa039]: use of address of unaligned structure member". Код будет нерабочий. Что, в общем-то, и ожидается. - LightElf(27.07.2020 00:31)
        
        Код будет где-то рабочий а где-то нет. На AVR рабочий, на Cortex-M3 и ESP32 рабочий а на M0 и ESP8266 получим hard fault. И варнинг тогда уж надо выдавать в зависимости от архитектуры процессора. - 3m(27.07.2020 07:16)
        
        Неа. IAR этот варнинг и на CM4 выдает. Этот код непортабелен и уже потому должен вызывать варнинг. Логика должна быть такая: "ты тут чего-то странное на$%евертил, я это как-то скомпилю, но не обижайся если что". . Другое дело, что "у меня все работает", потому что выровненность полей структуры достигается другими методами (о которых компилятор не знает). - LightElf(27.07.2020 14:48)

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