Почему-то с помощью SEH не удается отследить EXCEPTION_INT_OVERFLOW.
Не подавляется (обрабатывается) ли оно аппаратно?

FCM, такое аппаратное исключение вообще бывает? что-то сомневаюсь %)

Формально приведено в одной книжке (Рихтер "Windows via С/С++") в главе про SEH


Это сообщение отредактировал(а) FCM - 17.8.2009, 19:40

вообщето оно генерится инструкцией into
как вы его генерили?

FCM, представляешь, сколько бы проблем было при поднятии такого исключения на автомате?
флаг OF(overflow) очень часто используется штатно для определения критериев завершения циклов,
поэтому такое переполнение не генерируется по-умолчанию

если нужно, просто генерируй его сам:


into - тоже подойдет, но оно тестирует OF, конкретно по факту операции, типа такого:

никакой гарантии, что OF не будет сброшен\установлен кодом между непосредственной операцией сложения и __asm

Добавлено через 3 минуты и 57 секунд

в любой операции сравнения на больше\меньше проверяется равенство флагов знаков и переполнения

при чем тут сброс?

add, inc, sub, dec, mul - все устанавливают OF в соответствии с результатом,
сброс тут не нужен,
если нужно что-то более сложное - встроенный ассемблер в помощь,
а без него - RaiseException, как я уже показал

GremlinProg, 
RaiseException который ты показал сводит на нет весь смысл into, изза немеряного оверхеда, непонятно вообще зачем бросать EXCEPTION_INT_OVERFLOW если можно бросить чтоугодно, всеравно там if

как устанавливается и сбрасывается OF я знаю, любая арифметическая инструкция, в том числе cmp, между сложением и into поменяет OF, кроме того, порядок вызова операторов перед __asm никем не гарантируется, 
  a+=b; x+=y; __asm into
может скомпилироваться в аналог
  x+=y; a+=b; __asm into

into тут ни при чем, смысл RaiseException как раз в поднятии исключения без использования асма, и соответственно into
RaiseException - равнозначная замена, только с учетом того, что тут можно бросить не обязательно EXCEPTION_INT_OVERFLOW, а любое другое, которое программа в состоянии обработать (вплоть до критического)
любой программист в состоянии завести свой список исключений и работать с ним в дополнение ко всем системным исключениям (mc.exe в помощь)

if тут опять же ни при чем, т.к. от OF и  into тут уже ни чего не будет зависеть

не любая

чтобы порядок не имел значения, у программиста должен быть другой оч. полезный инструмент - голова


GoldFinch, если тебе есть что сказать в тему - я не против, всегда рад разделить мнение,
но если будешь по-прежнему опоражнять пустой стакан, я тебе в него налью воды, не сомневайся

GremlinProg, 
дополнительное вычисление(?) "result >> 32" +  if это в сотни раз медленнее однобайтовой into которая выполняется за 0 или 1 тактов,
это называется "оверхед"
без into это должно реализовываться как jo/jno - тот же if, и это замена одного подхода на другой, 
можно писать into, можно писать jo, это разная логика кода - исключение и условие


какая?


это вообще к чему?

это к теме не относится, причем даже  "сотни раз" - это уже перебор


поздравляю, GoldFinch, ты освоил начальные навыки ассемблера, только к теме это так же не относится


это было наглядно продемонстрировано моим первым постом

очевидно все те арифметические операции, которые это переполнение не генерируют: DIV, IDIV, и т.п.


это к тому, что если не предусмотрено вычисление выражения, в ходе которого происходит переполнение, то разницы нет, какая команда это переполнение сгенерировало, результат в любом случае будет неверным

Признаю я был не прав. Как часто бывает, уверенность в своих знаниях меня подвела. 
Решив посмотреть как ведет себя div, я скомпилил в фасме код

запустил, и получил пресловутый Integer Overflow. Все таки не into единым.


Уважаемый GremlinProg, опомнись, и перестать писать то чего не знаешь. Ты вводишь в заблуждение участников форума, да и выглядит это не красиво.
Любой справочник говорит: 
DIV -- Unsigned Divide 
Flags Affected
OF, SF, ZF, AR, PF, CF are undefined. 


За сим отправляюсь отдыхать недельку, пока основной акк в бане.

я даже сохраню это на память )

уважаемый GoldFinch, честно говоря не знаю где ты мог получить в этом коде Integer Overflow, очевидно где-то ранее предоставленного кода, но опираясь даже на справку, которую ты так любезно нам предоставил:

are undefined означает не определено, т.е. не затрагиваются, они могут затрагиваться любыми предыдущими операциями, но не данной

совсем не обязательно было лезть в бутылку, только ради того, чтобы посмешить народ,
хотя, признаю, тема стала интересна только благодаря тебе, спасибо!

Да никак не генерил - прочитал книгу, попробовал . И почему это называется аппаратным исключением, если я его сам должен генерить? Было бы разумным иметь опцию в свойствах проекта, включающую/отключающую генерацию этого исключения.

Кстати пробовал еще с помощью EXCEPTION_ARRAY_BOUNDS_EXCEEDED отловить выход за пределы С-массива -  то же безрезультатно (в Debug это ловилось RTL'ю, а в Release- никак)

A EXCEPTION_FLT_***  фиксируется (после того как контрольным словом отключить их FPU-обработу).
Хотя тут два момента непонятны. 
1) Если  аппаратное FLT-исключение нигде не обработано, Windows его определяет (выдает правильный 16-чный код исключения), но почему-то называет unknown software exception
2) Просматривал статусное слово различных FLT-операций и заметил, что в Release фиксируется меньше критических FLT-событий. Если Debug и Release отличается толко настройками RTL, то как настройки RTL влияют на FPU-обработку FLT-исключений.?

Если взять простое консольное приложение, то "казалось бы" после его одевания при компоновке в SEH-фреймы оно должно иметь внешний фрейм от windows, потом фреймы (или аналоги?) от RTL, потом пользовательские (если есть) ловушки, а аппаратные средства обработки еще глубже. И каким боком туда залезает RTL (в С++ еще минимально , в некоторых языках еще более выраженно).

Не совсем понятно, что собственно генерит аппаратные исключения - CPU/FPU или какие-нибудь драйвера. Также не понятно, как FPU обрабатывает EXCEPTION_FLT_*** действительно аппаратно или драйвера.  Функции VС++ напрямую работают c железом или через WinApi ? 
Например попытка открыть несуществующий файл - приводит к соответствующему errno. Кто его назначает? Это же программное исключение?



Это сообщение отредактировал(а) FCM - 18.8.2009, 18:06

ну, потому что процессор не знает ни EXCEPTION_INT_OVERFLOW, ни любой другой статус, привычный нам, он просто генерирует аппаратное прерывание, которое перемещает исполнение кода на соответствующий адрес в векторе прерываний, а оттуда уже операционка нас информирует о случившемся через SEH (в документации такие прерывания обозначаются через решетку: #OF(overflow), #DE(divide error) и т.п.)

в принципе, может и появится в будущем,
есть же опция /fp:except, которая расставляет WAIT'ы после любых обращений к FPU
тут в принципе аналогично - после целочисленных вычислений вставлять into, но по-моему, от этого будет только больше проблем, чем пользы

ну так проверка на выход за границы массива только в дебаге и ведется, можешь и в релизе ее включить, только зачем оно надо, это ведь отладочный механизм

сопроцессор и генерит

он не обрабатывает EXCEPTION_FLT_***
он обрабатывает свои контрольные регистры: если поднят флаг исключения (одного из 6), и если это исключение выключено по маске, то генерирует какое-то общее прерывание для исключений (смотри документацию, не помню какое именно)
если исключение маскируется, то FPU просто заменяет результат одним из табличных значений:

и продолжает работать дальше

с железом работают драйвера, а errno ставит CRT, и это уже не исключение, это что-то вроде упрощенного аналога для GetLastError