История изменений
Исправление olelookoe, (текущая версия) :
Стандарт не запрещает этого делать.
стандарты также не запрещают голой жопой сидеть на раскаленной сковородке, это да, тут не возразишь. однако я ни разу не встречал ни в каких текстах упоминаний о том, что сковорода может быть использована для таких (или тысяч возможных других) извращений. и вряд ли прочту. никакие стандарты не мешали и в будущем не помешают юным и не очень юным падаванам натягивать сову на глобус с особым цинизмом.
инструмент пилится под конкретную задачу. если кто-то потом решит что круглое кантуют, а квадратное перекатывают - это не проблема создателей круглого и квадратного.
30 лет назад по этой теме был отличный USENET-пост за авторством Doug Gwyn:
Чтобы привести определенный пример, драйверы устройств UNIX почти всегда кодируются полностью на C, и на PDP-11 и подобных архитектурах с привязкой к памяти ввода/вывода, некоторые регистры выполняют различные действия для операций «чтение байта», «чтение слова», «запись байта», «запись слова», «чтение-модификация-запись», или другие вариации операций по доступу к шине памяти. Попытки получить генерацию правильно работающего машинного кода драйвера на C было довольно затруднительным, с появлением трудно обнаруживаемых ошибок. Если используются компиляторы не от Ritchie, включение оптимизации также изменяло бы поведение программы. Как минимум одна версия компилятора UNIC (UNIX Portable C Compiler, PCC) имела специальный хак для распознавания конструкций наподобие следующей:
((struct xxx *)0177450)->zzz
Подобное выражение было бы потенциальной ссылкой на пространство ввода/вывода (регистры периферийного устройства), и в этом месте следует избегать чрезмерной оптимизации (когда константа попадает в область адресного пространства Unibus I/O). X3J11 решил, что проблему надо решать, и ввел «volatile» чтобы устранить необходимость в этих хаках. Однако хотя было рекомендовано для реализаций удовлетворять минимально возможной ширине для данных, квалифицированных как volatile, и было решено непрактичным настаивать на внедрении этого требования в каждой реализации; так что конструкторам была предоставлена некоторая свобода в разработке компиляторов.
Исходная версия olelookoe, :
Стандарт не запрещает этого делать.
стандарты также не запрещают голой жопой сидеть на раскаленной сковородке, это да, тут не возразишь. однако я ни разу не встречал ни в каких текстах упоминаний о том, что сковорода может быть использована для таких (или тысяч возможных других) извращений. и вряд ли прочту. никакие стандарты не мешали и в будущем не помешают юным и не очень юным падаванам натягивать сову на глобус с особым цинизмом.
инструмент пилится под конкретную задачу. если кто-то потом решит что круглое кантуют, а квадратное перекатывают - это не проблема создателей круглого и квадратного.
20 лет назад по этой теме был отличный USENET-пост за авторством Doug Gwyn:
Чтобы привести определенный пример, драйверы устройств UNIX почти всегда кодируются полностью на C, и на PDP-11 и подобных архитектурах с привязкой к памяти ввода/вывода, некоторые регистры выполняют различные действия для операций «чтение байта», «чтение слова», «запись байта», «запись слова», «чтение-модификация-запись», или другие вариации операций по доступу к шине памяти. Попытки получить генерацию правильно работающего машинного кода драйвера на C было довольно затруднительным, с появлением трудно обнаруживаемых ошибок. Если используются компиляторы не от Ritchie, включение оптимизации также изменяло бы поведение программы. Как минимум одна версия компилятора UNIC (UNIX Portable C Compiler, PCC) имела специальный хак для распознавания конструкций наподобие следующей:
((struct xxx *)0177450)->zzz
Подобное выражение было бы потенциальной ссылкой на пространство ввода/вывода (регистры периферийного устройства), и в этом месте следует избегать чрезмерной оптимизации (когда константа попадает в область адресного пространства Unibus I/O). X3J11 решил, что проблему надо решать, и ввел «volatile» чтобы устранить необходимость в этих хаках. Однако хотя было рекомендовано для реализаций удовлетворять минимально возможной ширине для данных, квалифицированных как volatile, и было решено непрактичным настаивать на внедрении этого требования в каждой реализации; так что конструкторам была предоставлена некоторая свобода в разработке компиляторов.