информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[C++] Если я все правильно понимаю, то это by design 30.05.03 17:01  Число просмотров: 926
Автор: Ktirf <Æ Rusakov> Статус: Elderman
Отредактировано 30.05.03 17:03  Количество правок: 1
<"чистая" ссылка> <обсуждение закрыто>
Начнем с цитат (выделение мое):
"Signals and exceptions don't mix well, and should be considered seperately..."

"...C++ does not guarantee that a signal-handling function is able to interact with any other part of a program. Creating a signal handler that throws an exception, for example, is undefined behavior in Standard C++."

Что касается g++, то в его случае, если я нигде не ошибся при проверках, undefined behaviour сводится ко вторичному SIGSEGV, который добивает программу непосредственно при попытке throw (да, кстати, обработка сигнала - это не обработка исключения, и нельзя там ставить throw без параметра).

На архитектуре Tru64 и, если я не ошибаюсь, в Cygwin'овской реализации g++ есть преобразование сигналов в исключения, но только если не установлен свой обработчик сигнала.

Что касается SIGSEGV самого по себе, то он специально сделан так, чтобы продолжить работу было нельзя. Другими словами, считается, что это фатальная ошибка, после которой работать становится невозможно. Строго говоря, так оно и есть, потому что один из случаев SIGSEGV делается так: объявляется указатель на функцию, ему присваивается 0, после чего вызывается "функция" на которую он указывает. Можно придумать еще хуже: функция модифицирует стек вызова (модификация стека вызова действительно используется, это не теория), записывает 0 как адрес предыдущего уровня в стеке, после чего возвращает управление. Понятно, что в таких условиях продолжение работы невозможно в принципе - непонятно, откуда и что продолжать. И во всех этих случаях вызывается один и тот же SIGSEGV, обработчик которого ни сном ни духом о том, почему этот сигнал пришел.

Так что сорри. Перемешивание сигналов и исключений по определению непереносимо между платформами, а SIGSEGV носит фатальный характер по причинам, изложенным выше. Для этого, в частности, если системой вызывается обработчик SIGSEGV, то он вызывается в цикле до тех пор, пока не убьет программу сам.
<programming> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach