Здравствуйте, Павел Кузнецов, Вы писали:
k>> Под виндами безо всяких хаков: k>>
k>> A* pA = new((void*)0) A;
k>>
ПК>Вот это и есть один из возможных "хаков".
Это не хак, а крах.
Undefined Behaviour с заведомым фейерверком. В нулевом адресе конструируем объект и
* либо сразу получаем AV (под виндами)
* либо затираем таблицу прерываний (x86 real mode) с последующими приключениями вплоть до форматирования винта
* либо гадим в ядро ОС, опять с последующими приключениями
Перекуём баги на фичи!
Re[6]: Почему в C/C++ не может быть объектов с нулевым адрес
Здравствуйте, Andrew S, Вы писали:
К>>* либо гадим в ядро ОС, опять с последующими приключениями
AS>Хорошая, однако, OC, которая позволяет приложениям так просто в себя гадить. Почему то сразу вспомнился ZX spectrum с его бейсиком
На архитектуре i8080/К580/Z80° первые сколько-то байт отводятся для обработки прерываний. Прерывание N просто выполняет jmp 8*N.
При ресете управление отдается на 0 адрес, так что штатное решение — разместить там ПЗУ.
А перепрограммируемые прерывания — это уже забота конкретной ОС...
° или я путаю... К580 (i80) и К1816 (PDP-11) изучал в институте, и давно это было...
... << RSDN@Home 1.1.0 stable >>
Перекуём баги на фичи!
Re: Почему в C/C++ не может быть объектов с нулевым адресом
Здравствуйте, Forrest_Gump, Вы писали:
F_G>Насколько я помню, в DOS по адресу 0000:0000 располагалась таблица векторов прерываний. F_G>То есть ячейка памяти с нулевым адресом — вполне реальный физический объект.
F_G>Так почему же F_G>
F_G>Гарантируется, что нет объектов с нулевым адресом. Следовательно, указатель, равный нулю, можно интерпретировать как указатель, который ни на что не ссылается.
Б.Страуструпп "Язык программирования C++".
лехко. Страус просто не понял. Насколько им в серъёз. Займутся....
Re[6]: Почему в C/C++ не может быть объектов с нулевым адрес
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Павел Кузнецов, Вы писали:
k>>> Под виндами безо всяких хаков: k>>>
k>>> A* pA = new((void*)0) A;
k>>>
ПК>>Вот это и есть один из возможных "хаков".
Так так. Для всех товарищей выше по этой ветке напоминаю Стандарт (очень древнее его положение 5.3.4 13).
13 [Note: unless an allocation function is declared with an empty exceptionspecification (15.4), throw(), it
indicates failure to allocate storage by throwing a bad_alloc exception (clause 15, 18.4.2.1); it returns a
nonnull pointer otherwise. If the allocation function is declared with an empty exceptionspecification, throw(), it returns null to indicate failure to allocate storage and a nonnull
pointer otherwise.]
If the allocation function returns null, initialization shall not be done, the deallocation function shall not be called, and the value of the newexpression shall be null.
14 [Note: when the allocation function returns a value other than null, it must be a pointer to a block of storage
in which space for the object has been reserved. The block of storage is assumed to be appropriately
aligned and of the requested size. The address of the created object will not necessarily be the same as that
of the block if the object is an array. ]
В данной строчке кода никакой объект не создаётся. Т.е. не вызывается конструктор. А указатель pA получает нулевое значение. Дальнейшее использование нулевого указателя для манипулирования с несуществующим объектом -- ... (дополните сами). Некоторые компиляторы проверку на ненулевой указатель вставляют прямо в конструкторы -- чтобы программисты не баловались с хаками, наверное.
AS>>Хорошая, однако, OC, которая позволяет приложениям так просто в себя гадить. Почему то сразу вспомнился ZX spectrum с его бейсиком
К>На архитектуре i8080/К580/Z80° первые сколько-то байт отводятся для обработки прерываний. Прерывание N просто выполняет jmp 8*N. К>При ресете управление отдается на 0 адрес, так что штатное решение — разместить там ПЗУ. К>А перепрограммируемые прерывания — это уже забота конкретной ОС...
К>° или я путаю... К580 (i80) и К1816 (PDP-11) изучал в институте, и давно это было...
Вроде примерно так и было. Только при включении попадали на некий отрицательный адрес, где был сразу jmp на начало кода инициализации.
Ну да ни в этом дело. Просто я не припомню ни одной современной мультизадачной ОС, которая позволяла простой записью по адресу убивать себя (win9х и т.п. за OC просьба не считать ).
Здравствуйте, SWW, Вы писали:
АТ>>Если на какой-то платформе машинный адрес 0 не является особым и зарезервированным, то вполне может быть, что присваивание указателю константного целочисленного значения 0 будет приводить к тому, что физически в это указатель будет ложиться, например, 0xFFFFFFFF или что-то в этом роде.
SWW>Хм, а как на такой платформе записать в указатель нулевое значение чтобы с ним работать, ведь оно там будет валидным?
Сам язык С++ не предоставляет гарантированных средств для записи в указатели конкретных (в смысле машинного адреса) значений. В С++ просто нет мест, где это было бы нужно. Да и на уровне языка просото не существует понятия "машинного адреса".
А для всяких платформенно-зависимых приложений существуют разнообразные платформенно-зависимые средства. Но эа этим надо уже лезть в документацию конкретной реализации, а не в язык С++.
Best regards,
Андрей Тарасевич
Re[9]: Почему в C/C++ не может быть объектов с нулевым адрес
Здравствуйте, Andrew S, Вы писали:
AS>Ну да ни в этом дело. Просто я не припомню ни одной современной мультизадачной ОС, которая позволяла простой записью по адресу убивать себя (win9х и т.п. за OC просьба не считать ).
MacOS с её корпоративной многозадачностью? Одна задача повисла — весь ящик курит.
vxWorks с вообще отсутствием защиты памяти. Стреляй — не хочу.
Перекуём баги на фичи!
Re[4]: Почему в C/C++ не может быть объектов с нулевым адрес
Здравствуйте, Andrew S, Вы писали:
К>>Наконец, по поводу аппаратных исключений в виндах. К>>Это сделано только для отладочных целей. Поскольку разыменование указателя, не указывающего на данные (т.е. нулевой указатель, указатели за конец объектов, инвалидные указатели) — это неопределённое поведение, то первая страница — 0x00000000-0x00001000 (кажется, так) — это ловушка: запрещено не только писать, но и читать её. Ведь помимо нулевого адреса, легко получить и близкие к нулю (например, второй элемент массива по нулевому указателю). К>>Виртуальной памяти много, поэтому мы можем выкинуть 4 килобайта из адресного пространства и не шибко расстроиться.
AS>Не 4, а 64 кб (10000h). Более того, еще есть верхний предохранительный блок (ниже 3-го гигабайта адресного пространства) — тоже 64 кб + защитные страницы (анти) переполнения стека для каждого треда (еще по 4-128 кб).
Стоп! Стоп! Стоп! По-моему , мы все отвлеклись от сути. вопрос стоял так:
почему нельзя программно заставить микропроцессор в защищенном режиме выработать на адресной шине адрес 0 и произвести операцию чтения/записи по этому адресу . В этом режиме программа не может сформировать реальный физический адрес. Это запретит процессор на аппаратном уровне.
Это не DOS , где CS:IP — реальные составляющие реального адреса . В рассматриваемом нами случае это всего лишь дескрипторы , которыми оперирует О.С. Твой 0 — не реальный адрес и к адресной шине никакого отношения не имеет. Это — мираж!
Whoa...I did a 'zcat /vmlinuz > /dev/audio' and I think I heard God...
Re[5]: Почему в C/C++ не может быть объектов с нулевым адрес
Здравствуйте, Handler, Вы писали:
H>Стоп! Стоп! Стоп! По-моему , мы все отвлеклись от сути. вопрос стоял так: H>почему нельзя программно заставить микропроцессор в защищенном режиме выработать на адресной шине адрес 0 и произвести операцию чтения/записи по этому адресу .
Здравствуйте, ArtDenis, Вы писали:
H>>Стоп! Стоп! Стоп! По-моему , мы все отвлеклись от сути. вопрос стоял так: H>>почему нельзя программно заставить микропроцессор в защищенном режиме выработать на адресной шине адрес 0 и произвести операцию чтения/записи по этому адресу .
AD>Можно. Только кому и для чего это нужно
Нельзя. На то он и защищённый режим. Только провалиться в нулевое кольцо и получить доступ к привилегированным командам.
Перекуём баги на фичи!
Re[7]: Почему в C/C++ не может быть объектов с нулевым адрес
Здравствуйте, Кодт, Вы писали:
AD>>Можно. Только кому и для чего это нужно К>Нельзя. На то он и защищённый режим. Только провалиться в нулевое кольцо и получить доступ к привилегированным командам.
Здравствуйте, Кодт, Вы писали:
К>В защищённом режиме эти данные лежат вне адресного пространства процесса. Хочешь к ним обратиться — потанцуй с бубном на ассемблере.
И как это делается на ассемблере?
Чисто спортивный интерес
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Почему в C/C++ не может быть объектов с нулевым адрес
К>>В защищённом режиме эти данные лежат вне адресного пространства процесса. Хочешь к ним обратиться — потанцуй с бубном на ассемблере.
IT>И как это делается на ассемблере? IT>Чисто спортивный интерес
На win nt дело хуже — заплатки выпускаются весьма оперативно, поэтому проще пользоваться почти документированными средствами — секцией "\\device\\physicalmemory". Впрочем, прочитать с ее помощью можно не все участки, да и к ассемблеру это уже отношения не имеет.
Здравствуйте, Handler, Вы писали:
H>Стоп! Стоп! Стоп! По-моему , мы все отвлеклись от сути. вопрос стоял так: H>почему нельзя программно заставить микропроцессор в защищенном режиме выработать на адресной шине адрес 0
В защищенном режиме НЕТ ПРАКТИЧЕСКИ НИКАКОЙ СВЯЗИ между сигналами на адресной шине и адресом в виртуальной памяти. (Обращаться к физическому адресу — вообще бессымсленное занятие) Т.е. нулевой адрес на самом деле совсем не нулевой в физической памяти. Отображением страниц на физическую память — дело специяльных таблиц GDT & LDT. Более того, отображение одного и того же виртуального адреса на физическую память может постоянно изменяться или вообще не существовать в данный момент времени из-за подкачки...
Если же речь о реальном режиме работы CPU — то тут и карты в руки. Разыменовывай нулевой указатель или пиши в него данные сколько твоеё душе угодно. Ещё посоветую книги "Внутреннее Устройство Window 2000" и "Недокументированный возможности Windows 2000"
Перекуём баги на фичи!
Если нам не помогут, то мы тоже никого не пощадим.
