Не фантазии, а реальность. И документы тут не при чём. Никакая оптимизация, дающая тот же результат, что и не оптимизированный вариант, стандартом не запрещена. Постоянно вижу такое, работая с Microchip XC16 и GNU Arm Embedded. У меня впечатление, что
SciFi системный программист, а не эмбеддер.
Подсказка: объявляя данные союзами с нужными типами, мы ограничиваем обращение к данным с этими типами без использования приведения типов. Приведение типа (uint8_t*) - зло, так как нарушает работу проверки соответствия типов перпроцессором и компилятором.
Мой пример здесь:
http://caxapa.ru/919408.html полезен тем, что исключает принудительное приведение типа, которое может замаскировать лютые ошибки.
Рекомендую:
Исключить "ручные" приведения типов. Там, где требуется обращение к типу, отличному от определённого ранее, использовать определение типа (typedef) с необходимыми союзами (union) и, при целесообразности, структурами данных.
Включить опцию компилятора "Make all warnings into errors". Когда типы данных определены должным образом, эта опция поможет отследить ошибки в приведениях типов при доступе к данным.
Поначалу "Make all warnings into errors" кажется адом. Но когда понимаешь, что приведение кода в порядок (см. рекомендацию) спасает от ада при отладке и отлавливает жуткие баги на этапе компиляции и даже подсветки синтаксиса, вопросов: "С какой целью пробовать?" не возникает.
С уважением.
P.S. Отказаться от принудительного приведения типа с "Make all warnings into errors" редко удаётся. К примеру, sprintf() требует первым аргументом (char*), а у меня в наличии (volatile uint8_t*). Приходится приводить к (*char), иначе не пускает. Пока не имею решения для такого случая и моя первая рекомендация "исключить", на самом деле, редко применима.
Nikolay_Po (04.05.2019 22:39 - 22:46, просмотров: 210) ответил SciFi на Это фантазии. Не надо фантазировать, когда есть нормативные документы. Советую в них заглядывать, кстати. Там есть ещё один соскок: "undefined behavior". В этом случае возможно всё. Но вряд ли это тот случай.