Средства и методы разработки

Это вопрос трактовки написанного. Если компилятор сам, своими "руками" выделил память для локальной переменной, по произвольному адресу, то по завершению этого контекста он имеет полное моральное право эту ячейку "убить". Как бы её не обзывал локально программист. Кто в, здравом уме, будет требовать неоптимизируемого обращения к переменной, которую никто нигде до этого не объявлял, не резервировал ей конкретную область памяти, не назначал конкретного адреса? Какие побочные эффекты могут быть? В нормальных условиях - никаких. Могут быть нюансы. Например, когда на при сборке, объектами Си пользуются ассемблерные модули и они обращаются к переменным Си. Но инструкции к компиляторам и сборщикам учат, в таких случаях, объявлять переменные глобальными в ассемблере, и Си обращается к переменным ассемблера, но не наоборот. С другой стороны, зачем объявлять переменную volatile, если она не может быть изменена побочными эффектами вне поля "зрения" компилятора? Но тогда что компилятор будет вычитывать без кэширования и куда будет писать, если памяти для переменной не было выделено заранее и сам компилятор назначил переменной её место? Это может быть как регистр процессора, так и память общего назначения. Какая сущность и где будет получать и менять данные переменной? -=- Если строго следовать логике стандарта, то как только переменную пометили модификатором volatile, она должна появиться в списке объектов сборщика, чтобы стать доступной для "побочных эффектов" и, как бы ни хотел оптимизировать компилятор, обращения к переменной должны быть сохранены и не кэшированы. То есть, оптимизация недопустима. Считаю это упущением стандарта. Оптимизация волатильных переменных "по Сладкоежке" хороша в случаях, когда вводится переменная, которая в перспективе может подвергаться побочным эффектам, но в текущей реализации таковой ещё не стала. А тот, кто обращается к данным из ассемблера или, тем более, аппаратно, не объявив переменную глобальной - сам себе злобный Буратино.