我不确定当前的情况如何，但是目前情况是FP异常检测支持与整数非常不同。整数除法陷阱很常见。 如果POSIXSIGFPE完全引发异常，则要求它引发。

但是，您可以找出它是哪种SIGFPE，以查看它实际上是除法异常。(不过，不一定要被零除：2的补码INT_MIN/ -1除陷阱，以及x64的x86 div以及idiv在64b / 32b除的商不适合32b输出寄存器时也陷阱。但是在使用的AArch64sdiv上不是这种情况。)

所述的glibc手册说明那BSD和GNU系统用于信号处理程序提供一个额外的精氨酸SIGFPE，这将是FPE_INTDIV_TRAP对被零除。POSIX文件FPE_INTDIV_TRAP作为一个可能的值siginfo_t的int si_code字段，在哪里系统siginfo_t包括构件。

如果Windows首先提供了一个不同的异常，或者将它像Unix一样捆绑了相同算术异常的不同样式，则为IDK。如果是这样，则默认处理程序将解码额外的信息，以告诉您它是哪种异常。

POSIX和Windows都使用短语“被零除”来覆盖所有整数除法异常，因此显然这是常见的缩写。对于确实了解INT_MIN / -1(带2的补码)的问题的人，短语“被零除”可以视为除法异常的同义词。该短语立即指出了不知道为什么整数除法可能会成为问题的人们的常见情况。

FP异常语义

对于大多数操作系统/ C ABI中的用户空间进程，默认情况下会屏蔽FP异常。

这是有道理的，因为IEEE浮点可以表示无穷大，并且具有NaN可以使用该值将误差传播到所有将来的计算中。

0.0/0.0 => NaN

如果x是有限的： x/0.0=> +/-Inf带有x的符号

当掩盖异常时，这甚至可以使诸如此类的事情产生明智的结果：

double x = 0.0;

double y = 1.0/x;   // y = +Inf

double z = 1.0/y;   // z = 1/Inf = 0.0, no FP exception

FP与整数错误检测

FP检测错误的方法非常好：当掩盖异常时，它们会在FP状态寄存器中设置一个标志，而不是进行捕获。(例如，x86的MXCSR用于SSE指令)。该标志将保持设置状态，直到手动清除为止，因此您可以检查一次(例如在循环之后)，以查看发生了哪些异常，而不是发生异常的位置。

已经提出了具有相似的“粘性”整数溢出标志来记录在一系列计算期间的任何时间是否发生溢出的提议。允许屏蔽整数除法异常在某些情况下会很好，但在其他情况下则很危险(例如，在地址计算中，您应陷阱而不是潜在地存储到虚假位置)。

但是，在x86上，要检测在一系列计算期间是否发生整数溢出，需要在每个计算之后放置一个条件分支，因为标志只是被覆盖了。MIPS的一条add指令将捕获有符号的溢出，而一条无符号的指令则永不捕获。因此，整数异常检测和处理的标准化程度要差很多。

整数除法不能选择生成NaN或Inf结果，因此以这种方式工作很有意义。

由整数除法产生的任何整数位模式都是错误的，因为它将表示特定的有限值。

但是，在x86上，如果掩盖了“无效的浮点”异常，则使用cvtsd2si或类似的转换指令将超出范围的浮点值转换为整数会生成“整数不确定”值。除符号位外，该值全为零。即INT_MIN。