在另一个问题中，有人想知道他们为什么会得到一个"浮点错误"，实际上他们的C ++程序中有一个整数除零。围绕这一点进行了讨论，有些人声称浮点异常实际上从未因浮点除以零而增加，而只是在整数除以零时出现。

这听起来很奇怪，因为我知道：

所有Windows平台上x86和x64上的MSVC编译代码报告int除以零为"0xc0000094：整数除以零"，浮点除以零为0xC000008E"浮点除以零"(启用时)

IA-32和AMD64 ISA将#DE(整数除法异常)指定为中断0.浮点异常触发中断16(x87浮点)或中断19(SIMD浮点)。

其他硬件具有类似的不同中断(例如，PPC在float-div-by上引发0x7000并且根本不捕获int / 0)。

我们的应用程序使用_controlfp_s内部函数(最终stmxcsr op)取消屏蔽零除零的浮点异常，然后捕获它们以进行调试。所以我在实践中肯定会看到IEEE754被零除的异常。

因此，我得出结论，有些平台将异常作为浮点异常报告，例如x64 Linux(无论ALU管道如何，都会针对所有算术错误提升SIGFPE)。

其他操作系统(如果您是操作系统，还是C / C ++运行时)报告整数除零作为浮点异常？

用户空间应用程序不会直接看到CPU中断，因为它们是由内核接收的。程序看到的内容取决于操作系统如何处理中断。

@KerrekSB确实。我问，"什么操作系统报告整数除以零作为浮点异常？"

你是？您的问题说明其他C或C ++运行时

@NathanOliver我已经解决了这个问题。我习惯于在C运行时方面考虑这个问题，因为当我第一次处理这类事情时，我正在编写内核级代码。

"其他什么操作系统/运行时......"是一个非常广泛的问题。但是，自从你问，MSVC 9.0(Windows 7)挂起，虽然如果它知道除数为0，编译器会发出警告。

由于问题标记为x86-64，您是否只在该硬件上寻找操作系统？

您似乎在询问如何定义未定义的行为。

@AlanStokes我问的是特定平台如何处理硬件定义的特定中断。

我认为可以询问UB上的实现如何表现，因为实现可以自由地定义某些UB作为实现定义，作为标准的扩展。

我认为这在我过去25年来使用的大多数Unix系统中都是常见的行为。

在x86的旁注中：有些可能称为整数除以零的异常可能并不总是准确的。如果整数除法溢出，则会抛出相同的异常。我更喜欢称它为整数除法异常。

在Linux / Unix上由于遗留原因，浮点和整数异常被映射到用户陆地信号SIGFPE。名称SIGFPE仅是名称的遗留"浮点异常"。它实际上只是意味着"算术异常"(包括整数和浮点)

我不确定目前的情况如何，但目前的情况是FP异常检测支持与整数非常不同。陷阱的整数除法很常见。 POSIX要求它提升SIGFPE，如果它根本引发异常。

但是，你可以理清它是什么类型的SIGFPE，看它实际上是一个除法异常。 (但不一定是除以0：2的补码INT_MIN / -1除法陷阱，当64b / 32b除法的商不适合32b输出时，x86的div和idiv也陷阱注册。但是在使用sdiv的AArch64上并非如此。)

glibc手册解释了BSD和GNU系统为SIGFPE的信号处理程序提供了额外的arg，除以零之外将是FPE_INTDIV_TRAP。 POSIX记录FPE_INTDIV_TRAP作为siginfo_t的int si_code字段的可能值，在siginfo_t包含该成员的系统上。

IDK，如果Windows首先提供不同的异常，或者它将事物捆绑到与Unix相同的算术异常的不同风格中。如果是这样，默认处理程序会对额外信息进行解码，以告诉您它是什么类型的异常。

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。

(参见英特尔手册，x86标签wiki中的链接。

旁注：彼得，正如我读到的那样，在我看到你的名字之前，我开始思考，"这看起来像彼得的答案之一"，基于风格和彻底性。果然;-)( + 1)为另一个伟大的答案，并保持良好的工作。

请原谅我在这方面很新，但是我们可以使用QNaN指向异常发生的位置，这样我们仍然可以检查一次，但看看这些异常发生在哪里？ @Peter我问"FP与整数错误检测"第一段中最后一行的b / c。

@Modulo：理论上是，如果硬件选择将指令指针复制到QNaN有效负载中，如果两个输入都不是NaN。然后NaN传播(当其中一个输入已经是NaN时)应保持该有效载荷不变，IIRC。不过，我不确定实际的硬件(如x86)是否能做到这一点。

@RobertHoughton这是IEEE 754故意允许的模型，但我认为没有人曾经在一些业余爱好项目之外实现它。 Peter在他的评论中提到了nan传播规则，这引入了一些复杂性 - 当一个操作有一个nan输入时，结果在大多数情况下应该是相同的nan quieted，但这不是IEEE 754的要求。当一个操作有多个时nan输入，没有指定如何选择的规则。它需要一些硬件协同设计来使这样的系统工作，但它绝对可行。

What other operating systems (or C/C++ runtimes if you are the operating system) report integer div-by-zero as a floating point exception?

答案取决于您是在内核空间还是用户空间。 如果你在内核空间，可以将"i / 0"放在kernel_main()中，让你的中断处理程序调用异常处理程序并暂停内核。 如果您在用户空间中，答案取决于您的操作系统和编译器设置。

AMD64 hardware specifies integer divide by zero as interrupt 0, different from interrupt 16 (x87 floating-point exception) and interrupt 19 (SIMD floating-point exception).

"除零"异常是用div指令除以零。 讨论x87 FPU超出了本问题的范围。

Other hardware have similarly different interrupts (eg PPC raises 0x7000 on float-div-by-zero and doesn't trap for int/0 at all).

更具体地说，00700映射到异常类型"Program"，其中包括一个启用浮点的异常。 如果尝试使用浮点指令进行除零，则会引发此类异常。

另一方面，整数除法是每个PPC PEM的未定义行为：

8-53 divw

If an attempt is made to perform either of the divisions—0x8000_0000 ÷

–1 or ÷ 0, then the contents of rD are undefined, as are

the contents of the LT, GT, and EQ bits of the CR0 field (if Rc = 1).

In this case, if OE = 1 then OV is set.

Our application unmasks floating-point exceptions for divide-by-zero with the _controlfp_s intrinsic (ultimately stmxcsr op) and then catches them for debugging purposes. So I have definitely seen IEEE754 divide-by-zero exceptions in practice.

我认为你的时间最好花在编译时而不是在运行时除以零。

对于用户空间，这发生在运行在POWER上的AIX上，在PA-RISC上运行的HP-UX，在x86-64上运行的Linux，在x86-64上运行的macOS，在Alpha上运行的Tru64和在SPARC上运行的Solaris上。

在编译时避免除零会好得多。

您确定Windows x86-64报告整数除以零作为浮点异常吗？我观察到它报告0xc0000094(整数除零)而不是0xC000008E(浮点除零)。配置是否具体？

哎呀，忘了我写了一些基础设施来实现这一目标。改变。